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1.  GENERAL  INFORMATION 


1.1  PURPOSE  OF  THIS  DOCUMENT 

This  document  records  current  agreements  on  implementation  details  of  OSI 
protocols  among  the  organizations  participating  in  the  NBS/OSI  Workshop 
Series  for  Implementors  of  OSI  Protocols.  These  decisions  are  documented 
to  facilitate  organizations  in. their  understanding  of  the  status  of 
agreements.  This  is  a standing  document  that  is  intended  to  be  updated 
after  each  workshop  (about  every  2-1/2  months). 

1.2  PURPOSE  OF  THE  WORKSHOPS 

In  February,  1983  NBS  organized  the  above  named  workshops  to  bring  together 
future  users  and  potential  suppliers  of  OSI  protocols.  The  workshop 
accepts  as  input  the  specifications  of  emerging  standards  for  protocols 
and  produces  as  output  agreements  on  the  implementation  and  testing 
particulars  of  these  protocols.  This  process  is  expected  to  expedite  the 
development  of  OSI  protocols  and  promote  interoperability  of  independently 
manufactured  data  communications  equipment. 

1.3  RELATIONSHIPS  OF  WORKSHOPS  TO  OUTGROWING  EVENTS  AND  ACTIVITIES 

The  workshops  are  held  for  those  organizations  expressing  an  interest  in 
implementing  OSI  protocols.  However,  there  is  no  corporate  commitment  to 
implementations  associated  with  workshop  participation.  Other  events 
stem  from  the  workshops  to  which  commitments  are  attached.  Sixteen 
organizations  did  make  formal  commitments  to  implement  and  demonstrate 
some  of  the  protocols  at  the  1984  National  Computer  Conference.  Commit- 
ments were  made  by  General  Motors,  Boeing  Computer  Services,  and  21 
vendors  to  demonstrate,  at  AUTOFACT  1985,  a set  of  OSI  protocols  known  as 
the  Manufacturing  Automation  Protocols  or  MAP  specification.  This  event 
was  an  outgrowth  of  the  workshops  in  that  the  implementation  decisions 
reached  in  the  workshops  were  used  for  the  AUTOFACT  demonstration.  However, 
the  AUTOFACT  demonstration  was  planned  and  carried  out  by  GM,  BCS,  and 
suppliers  they  selected.  This  event  had  no  further  affiliation  with 
the  workshops. 

A different  activity,  initiated  by  NBS,  is  the  OSINET,  which  is  to  be  a 
long  standing,  globally  distributed  network  that  is  put  in  place  for 
purposes  such  as  test  methods  development  and  testing  of  prototype 
implementations.  Presently,  25  organizations  have  committed  to  par- 
ticipate. As  with  the  AUTOFACT  demonstration,  protocols  used  on  OSINET 
are  those  agreed  to  in  the  workshop.  Also,  as  with  the  AUTOFACT  demon- 
stration, the  OSINET  has  no  other  affiliation  with  the  workshops.  Unlike 
the  AUTOFACT  demonstration,  however,  OSINET  participation  is  open  to  any 
organization  committing  to  the  OSINET  agreements. 
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1.4  RELATIONSHIP  OF  THE  WORKSHOPS  TO  THE  NBS  LABORATORIES 


As  resources  permit,  NBS,  with  voluntary  assistance  from  industry,  develops 
formal  protocol  specifications,  reference  implementations,  tests  and  test 
systems  for  the  protocols  agreed  to  in  the  workshops.  This  is  work  made 
available  to  the  industry  volunteers  and  to  others  making  valid  commitments 
to  organized  events  and  activities  such  as  NCC,  AUTOFACT,  and  OSINET,  As 
soon  as  this  work  can  be  adequately  documented  it  is  placed  in  the  public 
domain  through  submission  to  the  National  Technical  Information  Service. 

Any  organization  may  then  obtain  the  work  at  nominal  charge. 

The  NBS  laboratories  bear  no  other  relationship  to  the  workshops. 

1.5  STRUCTURE  AND  OPERATION  OF  THE  WORKSHOPS 

1.5.1  PI  enary 

The  main  body  of  the  workshops  is  a plenary  assembly.  Any  organization 
may  participate.  Representation  is  international.  NBS  prefers  for  the 
business  of  workshops  to  be  conducted  informally,  since  there  are  no 
correspondi ng  formal  commitments  within  the  workshops  by  participants  to 
implement  the  decisions  reached.  The  guidelines  we  follow  are:  1)  one 

vote  per  company  or  independent  division,  2)  only  companies  that  regularly 
attend  should  vote,  3)  only  companies  that  plan  to  sell  or  buy  a protocol 
should  vote  on  its  implementation  decisions,  4)  only  companies  knowledgeable 
of  the  issues  should  vote,  and  5)  no  proxy  votes  are  admissible. 

1.5.2  Special  Interest  Groups 

Within  the  workshops  there  are  Special  Interest  Groups  (SIGs).  The  SIGs 
receive  their  instructions  for  their  technical  program  of  work  from  the 
plenary.  The  SIGs  meet  independently,  usually  during  the  three  day  workshop. 
As  technical  work  is  completed  by  a SIG,  it  is  presented  to  the  plenary 
for  disposition.  Companies  participating  in  a SIG  are  expected  to  participate 
in  the  plenary.  Voting  rules  for  SIGS  are  the  same  as  voting  rules  for 
the  plenary. 

Special  Interest  Groups  sometimes  correspond  with  organizations  performing 
related  work,  such  as  ANSI  committees.  Such  correspondence  should  be 
sent  through  the  plenary  to  the  parent  committee,  such  as  ANSC  X3T5  or 
ANSC  X3S3.  When  SIG  meetings  take  place  between  workshops,  the  corre- 
spondence from  these  meetings  should  be  addressed  directly  to  the  parent 
committee  and  copied  to  the  workshop  plenary. 

Following  are  procedures  for  cooperative  work  among  special  interest 
groups. 

a)  Any  SIG  (SIG  1)  or  individual  having  issues  to  discuss  with  or 

requirements  of  another  SIG  (SIG  2)  should  bring  the  matter  to  the 
attention  of  the  chairperson  of  that  SIG  (SIG  2). 
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b)  The  SIG  2 chairperson  should  bring  the  matter  before  SIG  2 for  action. 

c)  SIG  2 should  respond  to  the  concerns  or  needs  of  SIG  1 or  the  individual 
in  a timely  manner. 

d)  If  the  matter  cannot  be  satisfactorily  resolved  or  if  the  request  is 
outside  the  charter  assigned  to  SIG  1,  then  it  should  be  brought 
before  the  plenary. 

e)  SIGs  are  expected  to  complete  work  in  a timely  manner  and  bring  the 
results  before  the  plenary  for  disposition.  However,  the  plenary  may 
elect  to  act  on  any  issue  within  the  scope  of  the  workshop  at  any  time. 

Following  are  the  current  charters  of  the  the  six  Special  Interest  Groups. 

FTAM  SIG 


Develop  phase  2 product-level  specifications  for  FTAM  as  requested  by  the 
Corporation  for  Open  Systems. 

Future  new  work  items  will  be  defined  in  a phase  3 specification.  It 
will  contain  only  extensions  of  phase  2 FTAM.  It  is  a goal  that  phase  3 
will  be  backward  compatible  with  phase  2 FTAM.  The  set  of  future  work 
items  listed  below  may  be  changed  by  the  plenary  if  the  work  is  more 
appropriate  for  other  SIGs. 

High  priority  work  items: 

- Develop  implementation  specifications  for  ISO  CASE  and  ISO 
Presentation  protocols 

- Clean  up  section  10  of  this  document 

- Specify  Reliable  File  Service 

- Specify  Recovery  and  Restart  Data  Transfer  functional 
units  in  the  user  correctable  file  service 

- Specify  concurrency  control  parameter. 


Low  priority  work  items: 

- Add  new  document  types/constraint  sets 

- Define  subset  of  authorization  requirements 

- Specify  Presentation  Context  Management  functional  unit. 
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X .400  SIG 


Develop  product-level  specifications  for  Message  Handling  Systems  using 
the  CCITT  X.400  Recommendations  as  requested  by  the  Corporation  for  Open 

Systems . 

Develop  abstract  tests  for  X.400,  as  requested  by  the  ad  hoc  rapporteur 
for  this  study  question  in  CCITT.  This  work  is  to  be  submitted  by  the 
plenary  (after  its  approval)  to  The  U.S.  Department  of  State  as  a proposed 
U.S.  contribution  to  CCITT  Study  Group  VII. 


Lower  Layer  SIG 

The  Lower  Layer  SIG  will  study  OSI  layers  1-4  and  produce  recommendations 
for  implementations  to  support  the  projects  undertaken  by  the  workshops 
and  the  work  of  the  other  SIGs.  Both  connectionless  and  connection- 
oriented  modes  of  operation  will  be  studied.  The  SIG  will  accept  direction 
from  the  plenary  for  work  undertaken  and  the  priority  which  it  is  assigned. 

The  objectives  of  the  Lower  Layer  SIG  are: 

o Study  OSI  layers  1-4  as  directed  by  the  plenary, 

o Produce  and  maintain  recommendations  for  implementation  of  these 
layers,  and 

o Where  necessary,  provide  input  to  the  relevant  standards  bodies 
concerning  layers  1-4,  in  the  proper  manner. 

o Begin  work  on  the  implementation  specification  of  the  ISO  Network  Layer 
Routing  Exchange  Protocol  prior  to  the  ISO  draft  achieving  DIS 
status. 

Performance  SIG 


The  plenary  will  provide  the  following  inputs  to  the  OSI  Performance  SIG: 

o the  set  of  applications  for  which  the  performance  of  OSI  protocols 
is  of  particular  concern, 

o the  requirements  for  each  application  including: 

- performance  targets 

- network  topology 

- background  network  loads 

- application  traffic  characteristics,  and 

o this  document,  "Implementation  Agreements  Among  Implementors  of 
OSI  Protocols". 
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The  objectives  of  the  OSI  Performance  SIG  are  to: 

o determine  whether  the  OSI  protocols  are  able  to  meet  these 
performance  requi rements , 

o report  these  determinations  to  the  plenary,  and 

o where  appropriate,  provide  input  to  the  voluntary  stanards  bodies 
concerning  changes  to  existing  standards  and  the  requirements  for 
new  ones,  in  the  appropriate  form. 

OSI  Security  Architecture  SIG 

GOAL:  To  develop  an  overall  OSI  Security  Architecture  which  is  consistent 

with  the  OSI  and  which  economically  satisfies  the  primary  security 
needs  of  both  the  commercial  and  Government  sectors. 

APPROACH:  To  define  a security  architecture  encompassing  the  security  addenda 

presently  being  specified  at  certain  OSI  layers,  the  required 
cryptographic  algorithms  and  related  key  management  functions, 
and  the  security  management  functions  which  must  be  performed 
between  the  layers  and  the  peer  entitities  defined  in  the  OSI 
architecture. 

Directory  Services  SIG 


The  DS  SIG  shall  develop  implementation  specifications,  at  the  request  of 
The  U.S.  Navy,  for  directory  user  agent  to  directory  systems  agent  and 
for  directory  systems  agent  to  directory  systems  agent.  These  specifications 
shall  be  based  upon  the  current  work  of  CCITT  and  ISO  in  this  area. 
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1.6  POINTS  OF  CONTACT 


OSI  Workshop  - General 
OSI  Workshop  - Registration 


John  Heafner,  NBS,  301/921-3537 


Mary  Lou  Fahey,  NBS,  301/921-3516 
Kim  Brink,  NBS,  301/921-3537 


FTAM  SIG 
X .400  SIG 
Lower  Layers  SIG 
Performance  SIG 
Security  SIG 
DS  SIG 
MAP 
TOP 

OSINET 


Rick  Peterson,  GM,  313/492-6705 
John  Stidd,  Xerox,  415/496-6527 
Kevin  Miles,  DEC,  +44-734-868711 


Mary  Jane  Strohl , CDS,  617/460-0808 
Denny  Branstad,  NBS,  301/921-3427 
J.  J.  Cinecoe,  WANG,  617/967-5514 


Gary  Workman,  GM,  313/575-0632 
Laurie  Bride,  BCS,  206/763-5719 


Steering  Committee 


Bob  Blanc,  NBS,  301/921-3817 
Andy  Poupart,  Tandem,  408/725-6480 
Mark  Shaw,  313/271-1500 
Paul  Borawski,  313/271-1500 


Technical  Committee 
SME  (MAP/TOP  Sponsorship) 


2.  THE  PROTOCOLS 


The  selected  protocols  for  which  implementation  agreements  have  been  made 
and  are  being  developed  are: 

0 IEEE  802.2  Logical  Link  Control 
0 IEEE  802.3  CSMA/CD  Access  Method 
0 IEEE  802.4  Token  Bus  Access  Method 
° CCITT  Recommendation  X.25 
° Private  Subnetworks 

0 Network  Dependent  Convergence  Sublayer  Protocol  between  X.25 
and  ISO  Connectionless  IP 

0 X.25  Packet  Layer  Protocol  to  support  the  Connection  Oriented 

Network  Service 

° ISO  Connectionless  Internetwork  Protocol 
° ISO  Transport  Classes  4 and  0 and  Connectionless  Protocols 
° ISO  Session  Protocol 

° ISO  File  Transfer,  Access  and  Management  Protocol 
0 ISO  Presentation  Layer  Protocol 
0 ISO  CASE  Protocol 

° CCITT  400  Series  Recommendations  for  Message  Handling  Facility 
0 CCITT  and  ISO  Directory  Services  Protocol 

Reference  documents  and  sources  for  obtaining  them  are  given  under  REFERENCES. 


3.1  IEEE  802.2  LOGICAL  LINK  CONTROL 

The  following  decisions  have  been  reached  with  respect  to  this  protocol. 


3.  LOCAL  AREA  NETWORKS 
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1.  Link  Service  Access  Point  (LSAP) 

The  IEEE  802  committee  has  assigned  the  code  below  to  address  systems 
using  ISO  IS  8473  connectionless  network  protocols.  Note  that  bit 
zero  is  transmitted  first. 

The  most  significant  bit  is  bit  7,  thus  this  bit  pattern  represents 
hexadecimal  FE. 


0 1 2 3 4 5 6 7 


0 

1 

1 

1 

1 

1 

1 

1 

Fig.  3.1  LSAP  bit  pattern 


2.  Type  and  Class 

Only  the  connectionless  type  1,  class  1 IEEE  802  link  service  will  be 
used. 

3.  Exchange  Identification  and  Test 

The  Exchange  Identification  (XID)  and  Test  (TEST)  will  not  be  sent. 

If  one  is  received  it  will  be  discarded. 

3.2  IEEE  802.3  CSMA/CD  ACCESS  METHOD 

The  following  decision  has  been  reached  with  respect  to  this  protocol. 

1.  Addressing 

The  48  bit  addressing  will  be  used  with  the  10  megabit/second 
baseband  coaxial  cable  specification, 

3.3  IEEE  802.4  TOKEN  BUS  ACCESS  METHOD 

The  workshop  participants  agreed  to  inclusion  of  token  bus.  The  following 
options  were  agreed  to  with  respect  to  Draft  F.  An  asterisk  means  that 
the  option  has  been  approved.  The  absence  of  an  asterisk  means  that  the 
option  has  not  been  approved. 

1.  Repeaters 

Active  Regenerative 

2.  Medium 

Single  Cable  Coax  * 

Dual  Cable  Coax 

3.  Trunk  Cable 

RG-6  * 

RG-11  * 

Semi-rigid  * 

Other  75  ohm  cables  * 

4.  Trunk  Connection  Unit 

75  ohm  tee  connector 
75  ohm  nondi rectional  passive 
impedence-matchi ng  tap 
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75  ohm  directional  passive  impedence- 

★ 

matching  tap 

5. 

Transmit  Carrier  Frequency 

RF 

Baseband 

★ 

6. 

Modulation 

Phase  Continuous  FSK 
Phase  Coherent  FSK 
AM/PSK 

★ 

7. 

Encodi ng 

Manchester 
Duobi  nary 

* 

8. 

Data  Rate 

1 Mb 

5 Mb 

★ 

10  Mb 

* 

9. 

Addressing 

2 octet 
6 octet 

* 

10. 

Connector  at  Station 

50  ohm  Male  BNC  Series 
75  ohm  Female  F Series 

* 

11. 

Priority  (4  levels) 

★ 

12. 

Group  Addressing 

* 

13. 

Station  Management 

14. 

Broadband  Channel  Assignments 

Forward  Reverse 

P 

3' 

* 

Q 

4' 

* 

R 

4M‘ 

★ 

S 

5' 

★ 

T 

6' 

★ 

U 

FM1 ' 

* 

4.  WIDE  AREA  NETWORKS 
4.1  CCITT  RECOMMENDATION  X.25 

When  providing  CONS,  it  has  been  agreed  to  use  X.25  as  the  standard  wide 
area  network  protocol.  Elements  of  X.25  are  explained  in  section  6.2.2. 

5.  PRIVATE  SUBNETWORKS 


5.1  PRIVATE  SUBNETWORKS 

The  architectures  agreed  upon  allow  the  use  of  private  subnetworks  in 
addition  to  private  X.25  subnetworks.  No  particular  private  subnetwork 
has  been  discussed. 
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6. 


NETWORK  LAYER 


6.1  CONNECTIONLESS  NETWORK  SERVICE  (CLNS) 

6.1.1  Provisions  of  CLNS  using  CLNP  (IS  8473) 

The  following  decisions  have  been  reached  with  respect  to  this  protocol. 

1.  The  "Protocol  for  providing  the  connection-less  service," 

ISO  IS  8473,  will  be  used  to  provide  the  CLNS. 

2.  The  full  conformance  protocol  will  be  used  for  concatenated 
networking.  The  inactive  subset  may  be  used  when  communicating 
on  a single  subnetwork."1’  The  inactive  subset  is  really  the 
absence  of  an  IP  and  is  so  indicated  by  an  IP  header  of  one 
octet  of  zeros.  The  nonsegmenting  subset  will  not  be  supported. 

6.1.2  Agreements  on  Protocol  Functions 

1.  For  purposes  of  demonstration  the  value  to  be  used  to  bound  the 
maximum  lifetime  of  the  internetwork  protocol  data  unit  is  three 
times  the  network  span.  The  span  of  the  network  is  considered 
to  be  the  number  of  intermediate  systems  between  source  and 
destination  plus  the  destination  end  system. 

2.  For  purposes  of  testing,  intermediate  and  end  systems  will  log 
the  following  conditions: 

o Discarded  protocol  data  units, 

o Error  protocol  data  units  (recorded  by  system  generating  the 
error  PDU) , and 

o Detection  of  protocol  data  units  containing  unsupported 
type  3 options. 

6.1.3  Agreements  on  Optional  Protocol  Functions 


1.  The  security  parameter  will  not  be  used. 

2.  Intermediate  systems  should  recognize  and  support  both  complete 
and  partial  source  routing. 

Although  end  systems  may  implement  source  routing  (of  either 
type),  any  requirement  for  end  system  source  routing  is  deferred 
for  future  study,  since  support  for  it  may  be  related  to  layer 
management  protocols. 


t When  using  the  inactive  subset,  the  NSAP  Selector  must  be  absent,  no 
segmenting  is  required,  and  the  AFI  and  subnetwork  number  must  be  the 
same,  i.e.,  denoting  a single  subnetwork  attachment. 
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3.  Partial  source  routing  will  be  supported  by  intermediate  systems. 
The  destination  should  log  the  route,  if  possible. 

4.  The  ISO  specification  will  be  followed  with  respect  to  quality 
of  service. 

5.  For  purposes  of  testing,  checksums  will  be  turned  on  and  used. 

In  operation  this  is  a local  decision. 


6.1.4  Network  Dependent  Convergence  Sublayer  Function  (CLNS  Over  X .25 ) 

A network  dependent  convergence  sublayer  protocol  operating  between  CCITT 
Recommendation  X.25  and  the  ISO  Connectionless  IP  has  been  agreed  to.  It 
shall  adhere  to  the  following. 

1.  Follow  ISO  8473  DAD1  (N3601)  Working  Paper  for  the  SNDCF  framework. 

2.  Only  initiate  one  SVC  for  all  outbound  PDUs  to  any  other  given 

intermediate  system  or  PDN  end  system.  Note:  this  results  in  at 

most  two  SVCs  between  any  pair  of  systems. 

3.  Open  a connection  upon  demand. 

4.  Disconnect  SVCs  by  administrative  request  and  a finite  timeout 
timer. 

5.  Use  the  default  throughput  class  from  APS. 

6.  Do  not  use  D-bit  or  Q-bit. 

7.  Negotiate  window  size  according  to  ISO  IS  8208.  A default  of  window 
size  two  must  be  supported. 

8.  Negotiate  packet  size  according  to  ISO  IS  8208.  A default  of  128 
octets/packet  must  be  supported. 

9.  The  SNDCF  will  "advertise"  support  for  SNSDUs  up  to  IK  via  the  X.25  M- 
bit  facility. 

10.  No  statistics  gathering  is  required  beyond  that  which  the  CLNS  may 
gather  for  the  X.25  packet  layer  or  for  SNDCF  entities. 

6.2  CONNECTION  MODE  NETWORK  SERVICE  (CONS) 

There  is  interest  among  a limited  set  of  participants  in  implementation 

of  the  connection  mode  network  service.  This  section  records  the 

agreement  of  the  workshop  on  the  provision  of  a connection  mode  network  service. 
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6.2.1  Introduction 


The  X.25  Packet  Level  Protocol  (PLP)  is  to  be  used  to  provide  of  the  OSI 
Connection-mode  Network  Service  (CONS).  This  proposal  is  independent  of 
lower  and  higher  layer  protocol  considerations,  which  are  also  discussed 
briefly  herein. 

When  providing  the  CONS,  the  following  shall  apply: 

a.  the  definition  of  the  CONS  is  as  specified  in  ISO  8348 
("Network  Service  Definition"); 

b.  the  mapping  of  the  elements  of  the  CONS  to  the  elements 
of  the  X.25/PLP  is  as  specified  in  ISO  8878  ("Use  of 

X.25  to  Provide  the  OSI  Connection-mode  Network  Service"); 
and 

c.  the  general  procedures  and  formats  of  the  X.25/PLP  are 
as  specified  in  ISO  8208  ("X.25  Packet  Level  Protocol 
for  Data  Terminal  Equipment");  it  should  be  noted  that 
this  standard  provides  for  the  use  of  the  X.25/PLP  in 
environments  in  addition  to  an  X.25  PSPDN,  such  as 
point-to-point  topologies  as  well  as  LANs.  (The  details 
of  how  to  use  the  X.25/PLP  in  LANs  are  given  in  ISO  8881, 
"Information  Processing  Systems  - Data  Communications  - 
Use  Of  The  X.25  Packet  Level  Protocol  in  Local  Area 
Networks.") 

6.2.2.  Provision  of  CONS  Using  X.25/PLP 

The  provision  of  the  CONS  using  the  X.25/PLP  is  as  described  in  (b)  above. 
This  section  provides  a brief  description  taken  directly  from  ISO  8878; 
for  more  detail,  see  ISO  8878. 

It  should  also  be  noted  that  the  X.25/PLP-1984  is  capable  of  supporting 
the  full  CONS,  including  qual ity-of-service  (QOS)  aspects.  The  X.25/PLP- 
1984  shall  be  used  in  LANS  and  in  packet-switched  networks  allowing  the 
use  of  the  elements  of  the  X.25/PLP-1984  needed  to  support  the  CONS.  In 
other  packet-switched-network  environments,  a Subnetwork  Dependent 
Convergence  Protocol  (SNDCP)  shall  be  used  in  conjunction  with  the  X.25/ 
PLP-1980  (see  section  6.2.5). 

6. 2. 2.1  Overview 


6 . 2 . 2 . 1 . 1  Elements  of  the  X.25/PLP  for  Support  of  the  CONS 

The  table  below  lists  the  packets  and  associated  fields  used  when  supporting 
the  OSI  CONS. 
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Table  6.1 


Packets  and  fields  of  the  X.25/PLP 
used  to  support  the  OSI  CONS 


PACKET  TYPES1 

FIELDS2 

CALL  REQUEST 
INCOMING  CALL 
CALL  ACCEPTED 
CALL  CONNECTED 

Facility  Field,  Call  and 
Called  User  Data  Field 

CLEAR  REQUEST 
CLEAR  INDICATION 

Clearing  Cause  Code  Field, 
Diagnostic  Code  Field, 
Facility  Field,  Clear  User 
Data  F ield 

DATA 

M-Bit,  User  Data  Field 

RESET  REQUEST 
RESET  INDICATION 

Resetting  Cause  Code 
Field,  Diagnostic  Code 
F ield 

RESTART  INDICATION 

Restarting  Cause  Code 
F ield. 

Diagnostic  Code  Field 

Notes : 

1.  The  packets  shown  in  the  table  are  used  in  support  of  the 
primitives  of  the  OSI  CONS.  Other  packets  not  shown  in 
the  table  (i.e.,  CLEAR  CONFIRMATION,  RESET  CONFIRMATION, 
and  RESTART  CONFIRMATION  packets)  are  essential  to  the  use 
of  the  packets  shown.  Yet  other  packets  (i.e.,  RESTART 
REQUEST,  DIAGNOSTIC,  REGISTRATION  REQUEST,  AND  REGISTRATION 
CONFIRMATION  packets)  have  no  relationship  to  the  provision  of 
the  OSI  CONS. 

In  line  with  these  agreements,  the  INTERRRUPT,  INTERRUPT 
CONFIRMATION,  RECEIVE  READY,  RECEIVE  NOT  READY,  AND  REJECT 
packets  are  not  needed  in  support  of  the  OSI  CONS  because  the 
corresponding  aspects  of  the  OSI  CONS  are  not  to  be  used  (i.e., 
the  Expedited  Data  Transfer  Service  and  the  Receipt  Confirmation 
Service  are  not  used).  However,  the  RECEIVE  READY  and  RECEIVE 
NOT  READY  packets  are  needed  for  the  proper  operation  of  the 
X.25/PLP. 


12 


2.  The  information  in  the  fields  shown  in  the  table  have  a direct 
relationship  to  the  parameters  associated  with  the  primitives  of 
the  OSI  CONS.  Other  fields  not  shown  in  the  table  (e.g.,  the 
Logical  Channel  Identifier,  the  Packet  Type  Identifier,  the 
Address  Length  Fields  and  the  Facility  Length  Field)  are  essential 
to  the  use  of  the  appropriate  packets. 

In  addition,  it  is  also  necessary  for  the  following  optional  user  facilities 
and  CCITT-Specif ied  DTE  Facilities  to  be  used  and/or  agreed  to: 

a.  optional  user  facilities  — 

o Fast  Select  (facility  used) 

o Fast  Select  Acceptance  (facility  agreed  to,  if  operating  in  a 
packet-switched  network  environment) 
o Throughput  Class  Negotiation  (facility  agreed  to  and  used),  and 
o Transit  Delay  Selection  And  Indication  (facility  used); 

Note:  When  operating  in  a DTE-to-DTE  environment  without  an  intervening  packet- 

switched  network,  the  use  of  the  Fast  Select  Facility  Must  also  be  agreed 
to  by  the  two  DTEs.  In  addition,  the  Fast  Select  Acceptance  Facility 
does  not  apply. 

b.  CCITT-Specif ied  DTE  facilities-- 

o Called  Address  Extension  (facility  used), 
o Calling  Address  Extension  (facility  used), 
o End-to-End  Transit  Delay  Negotiation  (facility  used), 
o Expedited  Data  Negotiation  (facility  used),  and 
o Minimum  Throughput  Class  Negotiation  (facility  used). 

Elements  of  the  X.25/PLP  not  needed  in  support  of  the  CONS  are: 

a.  Q-bit 

b.  Permanent  Virtual  Circuits  (PVCs); 

c.  Diagnostic  packets;  and 

d.  optional  user  facilities  other  than  those  listed  above. 

Elements  of  the  X.25/PLP  not  used  within  the  scope  of  these  agreements  are: 

a.  D-bit  and 

b.  INTERRRUPT  packets 

6. 2. 2. 1.2  General  Operation  of  the  X.25/PLP-1984  for  Supporting  the  OSI  CONS 

The  X.25/PLP  can  be  used  to  provide  the  OSI  CONS  in  an  end  system  connected 
to  a public  or  private  X.25  packet-switched  network  environment.  It  can  also 
be  used  in  environments  where  the  end-system  is  connected  to  a Local  Area 
Network  or  where  end  systems  are  connected  by  a dedicated  path  or  by  a 
circuit-switched  connection. 
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The  NS  provider  (more  particularly,  the  Network  Layer  (NL)  entity  in  an 
end-system)  must  provide  a translation  between 

a.  the  primitives  and  parameters  of  the  OSI  CONS;  and 

b.  the  packets  and  associated  fields  of  the  X.25/PLP. 

Request  and  response  primitives  are  translated  into  packets  to  be 
transmitted  across  the  DTE/DXE  interface  by  the  NL  entity.  Received 
packets,  where  appropriate,  are  translated  by  the  NL  entity  into  indication 
and  confirm  primitives.  These  translations  are  shown  in  sections  6. 2. 2. 2 through 
6.2.2. 7. 

Note:  The  Network  Service  Definition  specifies  valid  sequences  of 

primitives  at  a NC  endpoint  and  valid  parameter  responses  at  the 
called  NC  endpoint  to  Receipt  Confirmation  negotiation.  Expedited 
Data  negotiation,  and  QOS  parameter  negotiation.  The  necessity 
for  the  NL  entity  to  police  compliance  and  the  NL  entity  actions 
to  be  taken  on  non-compliance  are  a local  matter  and  not  subject  to 
standard izat  ion . 

There  is  also  a relationship  between  some  local  mechanism  used  to  identify 
a particular  Network  Connection  (NC)  and  a Logical  Channel  (LC)  number 
used  to  identify  a particular  virtual  circuit.  This  relationship  is  a 
local  matter  and  is  not  discussed  here. 

6. 2. 2. 2 Network  Connection  Establishment  Phase 

Table  6.2  shows  the  relationships  between  the  primitives/parameters  used 
during  the  Network  Connection  Establishment  Phase  and  the  packets/f ields 
associated  with  the  Call  Setup  Procedures. 
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Table  6.2 


CONS:  X.25/PLP  mapping  for  the  network  connection  establishment  phase 


CONS 

X.25/PLP-1984 

PRIMITIVES: 

PACKETS: 

N-CONNECT  request 

CALL  REQUEST 

N-CONNECT  indication 

INCOMING  CALL 

N-CONNECT  response 

CALL  ACCEPTED 

N-CONNECT  confirm 

CALL  CONNECTED 

PARAMETERS: 

FIELDS  (INCLUDING  FACILITIES): 

Called  Address 

Called  Address  Extension  Facility 

Cal  1 ing  Address 

Calling  Address  Extension 
Facil  ity 

Responding  Address 

Called  Address  Extension  Facility 

Receipt  Confirmation 
Select  ion 

See  Note  1 

Expedited  Data  Selection 

See  Note  1 

QOS  Parameter  Set 

Throughput  Class  Negotiation 
Facil  ity2 

Minimum  Throughput  Class 
Negotiation  Facility 
Transit  Delay  Selection  And 
Indication  Facility 
End-to-End  Transit  Delay 
Negotiation  Facility 

NS-User-Data 

Call  and  Called  User  Data  Field 
Fast  Select  Facility2 

Notes  to  Table  6.2: 

1.  Within  the  scope  of  these  agreements,  the  Receipt  Confirmation 
Service  and  Expedited  Data  Service  will  not  be  used.  Therefore, 
the  Network  Service  provider  will  indicate  the  unavailability 

of  these  services  even  if  requested  by  the  Network  Service  user. 

To  do  this  does  not  require  an  explicit  protocol  mechanism. 

2.  For  proper  operation,  this  optional  user  facility  must  also  be 
agreed  to  for  use  on  the  interface. 

3.  For  proper  operation,  the  Fact  Select  Acceptance  Facility  must  also 

be  agreed  to  on  the  interface  when  accessing  a packet-switched  network. 
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6. 2. 2. 3 Network  Connection  Release  Phase 


Table  6.3  shows  the  relationships  between  the  primitives/parameters  used 
during  the  Network  Connection  Release  Phase  and  the  packets/f ields  associ- 
ated with  the  Call  Clearing  Procedures. 

Table  6.3 

CONS:  X.25/PLP  mapping  for  the  network  connection  release  phase 


CONS 

X.25/PLP-1984 

PRIMITIVES: 

PACKETS: 

N-DISCONNECT  request 
N-DISCONNECT  indication 

CLEAR  REQUEST 

CLEAR  INDICATION,  RESTART  INDICATION!, 
CLEAR  REQUEST2 

PARAMETERS: 

FIELDS  (INCLUDING  FACILITIES): 

Originator  and  Reason 

Cause  Code  and  Diagnostic  Code  Fields^ 

NS-User-Data 

Clear  User  Data 

Responding  Address 

Called  Address  Extension  Facility 

Notes  to  Table  6.3: 

1.  Receipt  of  a RESTART  INDICATION  packet  should  be  treated  as 
receipt  of  a CLEAR  INDICATION  packet  for  every  logical  channel 

« and  then  mapped  to  an  N-DISCONNECT  indication  primitive  for 

every  active  NC  associated  with  the  Packet  Level  Protocol  being 
restarted.  The  Restarting  Cause  Code  and  Diagnostic  Code  Fields 
are  then  treated  in  the  same  manner  as  the  Clearing  Cause  Code 
and  Diagnostic  Code  Fields. 

2.  Used  only  when  the  NL  entity  in  the  end  system  originates  an  N- 
DISCONNECT  indication  primitive. 

3.  The  combination  of  Cause  Code  and  Diagnostic  Fields  is  mapped 
to/from  the  combination  of  Originator  and  Reason  parameters. 
Where  the  IS  8208  diagnostic  codes  are  not  provided,  all 
Cause/Diagnostic  code  combinations  can  be  mapped  to  the 
Orignator/Reason  parameter  values  of  "Undefined". 

6. 2. 2. 4 Data  Transfer  Phase  — Data  Transfer  Service 

Table  6.4  shows  the  relationships  between  the  primitives/parameters  used 
for  the  Data  Transfer  Service  and  the  packets/f ields  associated  with  the 
Data  Transfer  Procedures. 
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Table  6.4 

CONS:  X.25/PLP  mapping  for  the  data  transfer  service 


CONS 

X.25/PLP-1984 

PRIMITIVES: 

PACKETS: 

N-DATA  request 

DATA 

N-DATA  indication 

DATA 

PARAMETERS: 

FIELDS: 

NS-User-Data 

User  Data,  M-bit 

Confirmation  Request 

See  Note  1 

Note  to  Table  6.4: 

1.  Since  the  Receipt  Confirmation  Service  is  not  to  be  provided,  a 
Confirmation  Request  is  not  valid. 


6. 2. 2. 5  Data  Transfer  Phase  — Receipt  Confirmation  Service 
This  service  is  not  provided  within  the  scope  of  these  agreements. 


6. 2. 2. 6  Data  Transfer  Phase  — Expedited  Data  Transfer  Service 
This  service  is  not  provided  within  the  scope  of  these  agreements. 


6. 2. 2. 7  Data  Transfer  Phase  --  Reset  Service 

Table  6.5  shows  the  relationships  between  the  primitives/parameters  used 
for  the  Reset  Service  and  the  packets/f iel ds  associated  with  the  Reset 
Procedures. 
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Table  6.5 


CONS:  X.25/PLP  mapping  for  the  reset  service 


CONS 

X.25/PLP-1984 

PRIMITIVES: 

PACKETS: 

N-RESET  request 
N-RESET  indication 
N-RESET  response 
N-RESET  confirm 

RESET  REQUEST 

RESET  INDICATION,  RESET  REQUEST1 

none 

none 

PARMETERS: 

FIELDS: 

Originator  and  Reason 

Cause  Code  and  Diagnostic  Code 
F ields^ 

Notes  to  Table  6.5: 

1.  Used  only  when  the  NL  entity  in  the  end  system  originates  an 
N-RESET  indication  primitive. 

2.  The  combination  of  Cause  Code  and  Diagnostic  Code  Fields  is  mapped 
to/from  the  combination  of  Originator  and  Reason  parameters. 

Where  the  IS  8208  diagnostic  codes  are  not  provided,  all 
Cause/Diagnostic  code  combinations  can  be  mapped  to  the 
Originator/Reason  parameter  values  of  "Undefined". 


6.2.3.  Requirements  for  Underlying  Layer 

As  cited  in  IS  8208,  the  X.25/PLP  requires  the  following  of  the 
underlying  Layer  2: 

a.  low  duplication  rate; 

b.  low  missequencing  rate; 

c.  low  undetected  bit-error  rate;  and 

d.  low  loss  rate. 

When  operating  in  a packet-switched  (X.25)  network  environment,  the 
underlying  LAPB  protocol  ensures  these  requirements.  When  operating  in  a 
LAN  environment,  LLC  1 can  be  used.  Considerations  for  LLC1  are  given  in 
DP  8881. 


6.2.4.  Consideration  of  OSI  Transport  Layer  Protocol  Class 

It  may  be  useful  to  explore  the  desirability  of  an  alternative  to  the 
Transport  Class  4 protocol  for  use  over  the  CONS.  See  section  7,  "Transport." 
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6.2.5  Subnetwork  Dependent  Convergence  Protocol 


In  cases  where  an  end  system  is  required  not  to  use  the  elements  of  the 
X.25/PLP-1984  needed  to  support  the  OSI  CONS  (e.g.,  when  operating  in  a 
packet-switched  network  environment  that  will  treat  as  an  error  the  use 
of  any  of  the  CCITT-Specif ied  DTE  facilities),  then  it  shall  use  a 
Subnetwork  Dependent  Convergence  Protocol  (SNDCP)  to  provide  the  necessary 
elements  of  the  OSI  CONS  to  the  Network  Service  user.  These  elements 
involve  certain  aspects  of  the  Network  Connection  Establishment  Phase  and 
the  Network  Connection  Release  Phase. 

The  SNDCP  to  be  used  is  referred  to  as  the  Alternative  Procedures  for 
Network  Connection  Establishment  and  Release  in  DP8878.  The  procedures 
for  the  data  transfer  phase  of  the  SNDCP,  as  specified  in  DP8878,  are 
essentially  the  same  as  those  in  sections  6. 2. 2. 4 through  6. 2. 2. 7 of  this 
document. 


6. 2. 5.1  Network  Connection  Establishment  Phase 


The  procedures  for  this  phase  are  as  specified  in  DP8878,  Annex  A,  Section 
6.1(b)  (the  Alternative  Network  Connection  Establishment  Procedure). 

These  procedures  use: 

(a)  a CALL  REQUEST  packet  containing  (in  addition  to  the  packet 
header,  the  Address  Fields,  and  other  facilities): 

- the  Throughput  Class  Negotiation  Facility  if  available; 
otherwise,  the  throughput  of  the  virtual  circuit  must  be 
known  a priori  (by  way  of  the  Default  Throughput  Classes 
Assignment  Facility,  for  example),  and 

- a Call  User  Data  Field  containing  three  octets:  a one-octet 
Protocol  ID  identifying  the  X.25/PLP-1980  SNDCP  encoded  X ' 84 ' 

(as  assigned  by  ISO)  and  a two-octet  Continuation  Parameter 
encoded  X 1 2D00 ' to  indicate  the  first  M-bit  sequence  (MBS)  of 
DATA  packets  will  contain  additional  Network  Connection  (NC) 
Establishment  parameters; 

(b)  a CALL  ACCEPTED  packet  with  necessary  information  for  proper 
X.25  subnetwork  interface  operation  but  without  any  NC 
Establishment  parameters; 

(c)  an  MBS  of  one  or  more  DATA  packets  with  the  Q-bit  set  to  1, 

sent  by  the  originator  of  the  NC  Establishment  attempt,  containing 
all  necessary  NC  Establishment  parameters  encoded  according 
to  DP8878,  Annex  A,  Section  8.7(c)  (this  MBS  is  known  as  an  N-CR 
message);  and 

(d)  an  MBS  of  one  or  more  DATA  packets  with  the  Q-bit  set  to  1, 
sent  by  the  recipient  of  the  NC  Establishment  attempt  (assuming 
NC  acceptance),  containing  all  necessary  NC  Establishment 
parameters  encoded  according  to  DP8878,  Annex  A,  Section  8.7(d) 
(this  MBS  is  known  as  an  N-CC  message);  see  section  6. 2. 5. 2 for 
NC  refusal. 


19 


The  transit  delay  of  each  subnetwork  must  be  estimated. 

Similar  to  the  use  of  the  X.25/PLP-1984m  the  following  items  are  to 

be  noted: 

(a)  the  Network  Service  provider  will  indicate  the  unavailability, 
during  NC  Establishment,  of  the  Receipt  Confirmation  Service  and 
the  Expedited  Data  Service;  therefore,  no  protocol  mechanisms  are 
necessary  for  the  negotiation  of  these  services;  and 

(b)  NSAP  Addresses  are  carried  entirely  in  the  Address  Extension  Fields 
of  the  N-CR  and  N-CC  messages. 

A Connect  Response  Timer  may  be  used  per  DP8878,  Annex  A,  Section 

6.8(a). 


Figure  6.1  shows  the  NC  Establishment  Phase. 


N-CONNECT 

CALL  REQUEST/ 

REQUEST 

INCOMING  CALL 

CALL  ACCEPTED/ 

CALL  CONNECTED/ 

> 1 DATA  WITH  N-CR 

N-CONNECT 

> 1 DATA  WITH  N-CC 

INDICATION 

N-CONNECT 

RESPONSE 

N-CONNECT 

CONFIRM 

Figure  6.1  Successful  NC  establishment 


6. 2. 5. 2 Network  Connection  Release  Phase 


The  procedures  for  this  phase  are  as  specified  in  DP8878,  Annex  A,  Section 
6.2  (b)  (the  Alternative  Network  Connection  Release  Procedure).  These 
procedures  are  also  used  to  refuse  an  NC  establishment  attempt.  These 
procedures  use: 


(a)  an  MBS  of  one  or  more  DATA  packets  with  the  Q-bit  set  to  1, 
sent  by  the  originator  of  the  NC  release,  containing  all 
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necessary  NC  Release  parameters  encoded  according  to  DP8878, 
Annex  A,  Section  8.8(a)  (this  MBS  is  known  as  an  N-DR  message 
and  serves  as  an  "invitation  to  clear"  (that  is,  initiate  X.25 
clearing  procedures  to  the  recipient);  and 

(b)  the  X.25  CLEAR  REQUEST/ INDICATION  packet  as  indicated  in  DP8878, 
Annex  A,  Section  8.8(b). 

The  above  procedures  apply  to  NC  release  when  initiated  by  the  Network 
Service  user.  When  initiated  by  the  NS  provider,  the  N-DR  message  will 
not  be  sent  but  the  Originator  and  Reason  parameter  values  shall  both  be 
"undefined." 

A Disconnect  Response  Timer  may  be  used  per  DP8878,  Annex  A,  Section 

6.8(b). 

Figure  6.2  shows  the  NC  Release  Phase. 


6. 2. 5. 3  Data  Transfer  Phase  - Data  Transfer  Service 

The  Data  Transfer  Service  for  the  X.25/PLP-1980  SNDCP  is  the  same  as  for 
the  X.25/PLP-1984  procedures  (see  section  6. 2. 2. 4 of  this  document). 


6. 2. 5. 4  Data  Transfer  Phase  - Receipt  Confirmation  Service 

As  for  the  X.25/PLP-1984  procedures,  this  service  is  not  provided  within 
the  scope  of  these  agreements. 


6. 2. 5. 5 Data  Transfer  Phase  - Expedited  Data  Transfer  Service 

As  for  the  X.25/PLP-1984  procedures,  this  service  is  not  provided  within 
the  scope  of  these  agreements. 

6. 2. 5. 6 Data  Transfer  Phase  - Reset  Service 

The  Reset  Service  for  the  X.25/PLP-1980  SNDCP  is  the  same  as  for  the 
X . 25/ PLP-1 984  procedures  (see  section  6. 2. 2. 7 of  this  document). 
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N-CONNECT 

CALL  REQUEST/ 

REQUEST 

INCOMING  CALL 

> 1 CALL  ACCEPTED/ 

CALL  CONNECTED 
> DATA  WITH  N-CR 

N-CONNECT 

INDICATION 

N-DISCONNECT 

>1  DATA  WITH  N-DR 

N-DISCONNECT 

INDICATION 

CLEAR  REQUEST/ 

REQUEST 

CLEAR  INDICATION 

(a)  NC  ESTABLISHMENT  REFUSAL 


• 

• 

NORMAL  DATA 

>1  DATA  WITH  N-DR 

N-DISCONNECT 

N-DISCONNECT 

CLEAR  REQUEST/ 

REQUEST 

INDICATION 

CLEAR  INDICATION 

(b)  NC  RELEASE  AFTER  DATA  TRANSFER 
Figure  6.2  NC  release 

6.2.6  Interwork ing 

Interworking  between  subnetworks  needs  to  be  specified.  The  principles 
of  the  Internal  Organization  of  the  Network  Layer,  DP  8648,  need  to  be 
addressed.  A generalization  of  these  principles  for  the  OSI  CONS  case 
is  shown  in  F igure  6.3. 
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- Routing  and  Relaying  - 

X.25 

X.25 

PLP* 

PLP* 

Layer  2 

Layer  2 

Protocol 

Protocol 

Layer  1 

Layer  1 

Protocol 

Protocol 

*This  can  be  either  X.25/PLP-1984  or  X.25/PLP-1980  with  an  SNDCP  (see 
Section  6.2.5). 

Figure  6.3  Generalized  interworking  for  OSI  CONS 


The  detailed  behavior  and  properties  of  the  Interworking  Unit  are  to 
be  specified  in  future  extensions  of  this  document.  DP8881  and  DP  8878 
discuss  various  aspects  of  interworking. 


6.3  ADDRESSING  AND  ROUTING  CRITERIA 

The  following  have  been  agreed  to. 

1.  Do  not  go  beyond  ISO  routing  standardization  efforts. 

2.  Keep  the  end  system  as  simple  as  possible.  Put  the  needed  compleity 
into  the  intermediate  systems.  Minimize  memory  overhead  and  enhance 
performance  in  the  end  systems. 

3.  Addressing  and  routing  decisions  should  include  the  NBS  OSINET 

that  permits  inclusion  of  private  subnetworks  and  end  systems  on  PDNs. 

4.  Permit  multiple  subnetwork  (alternate  paths)  in  a single  intermediate 
system. 

5.  Allow  expandability  for  additional  functionality  beyond  that  required 
for  a specific  demonstration. 

6.  Support  a certain  minimal  topology.  Accommodate  multiple  LANs,  WANs, 
and  private  subnetworks. 

7.  Facilitate  efficient  implementation  of  intermediate  systems.  Minimize 
memory  overhead  and  enhance  performance  of  intermediate  systems. 
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8.  The  OSINET  will  accommodate  end  systems  attached  directly  to 
PDNs  as  one  requirement. 

6.4  GENERAL  ADDRESSING  AND  ROUTING  PRINCIPLES 

The  following  have  been  agreed  to. 

1.  Support  DAD2 . This  supports  criterion  no.  1. 

2.  Routing  Management 
Static  Routing: 

All  end  systems  and  intermediate  systems  will  provide  a local 
mechanism  to  manipulate  (and  optionally  create)  the  local  routing 
table.  Consistency  checking,  configuration,  and  updating  of  a local  table 
with  all  other  tables  will  be  performed  by  human  operators.  The  lack 
of  flexibility  induced  by  static  procedures  can  be  minimized  with  the 
use  of  the  following  aids: 

- alternate  static  routes 

- route  update  utility 

- FTAM  route  table  distribution 

- table  format  via  X.409  (ASN-1)  encoding. 

Dynamic  Routing: 

Endsystem-Intermediate  System  - A standard  that  provides  the  functionality 
of  dynamic  routing  must  be  provided.  The  protocol  referenced  in  the 
"References"  section.  Item  ISO  18,  "Network  Layer  Management  Protocol...", 
provides  for  this  functionality  between  end  and  intermediate  systems. 

This  standard  is  expected  to  be  endorsed  (and  appropriate  implementor 
agreements  drafted)  to  provide  this  function  at  a time  when  it  reaches 
the  "Draft  Proposal"  status. 

Intermediate  system-intermediate  System 

To  be  determined 

3.  Routing  Principles 

The  algorithm  and  data  structures  used  for  routing  are  not 
specified  by  this  document.  Implementors  are  free  to  perform 
these  functions  in  the  manner  which  is  most  appropriate  for 
their  system  environment.  However,  all  implementations  must  have 
the  following  characteristics: 

a)  end-systems 

End-systems  must  recognize  a destination  address  on  a directly 
connected  subnet  and  send  the  NPDU  to  the  destination  system. 

When  an  NPDU  is  destined  to  a system  that  is  not  on  a directly 
connected  subnet,  the  NPDU  must  be  sent  to  an  intermediate 
system  for  further  routing.  The  end  system  may,  but  is  not 
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required  to,  choose  the  intermediate  system  used  on  the  basis  of 
the  destination  subnet. 

b)  intermediate  systems 

For  static  routing,  intermediate  systems  must  recognize  all 
assigned  subnetwork  addresses  and  route  NPDU's  in  the  following 
way:  If  an  NPDU  is  destined  to  an  end  system  which  is  connected 

to  the  same  subnet  as  the  intermediate  system,  the  NPDU  is  sent 
directly  to  the  end  system.  If  an  NPDU  is  destined  to  an  end 
system  which  is  not  connected  to  the  same  subnet  as  the  interme- 
diate system,  the  NPDU  is  sent  to  an  appropriate  intermediate 
system  for  further  routing.  If  an  NPDU  is  destined  to  an  end 
system  on  an  unknown  subnet,  the  NPDU  is  discarded.  If  the 
error  flag  is  set,  an  error  NPDU  is  sent  to  the  source  address 
specified  in  the  errant  NPDU. 

4.  There  is  a single  NSAP  selector  for  each  NSAP  within  an  end 
system.  For  each  end  system  NSAP,  one  and  only  one  NSAP  address 
will  be  used  to  identify  the  NSAP.  This  conforms  to  the  require- 
ments of  DAD2  and  supports  criterion  no.  1 to  comply  with  current 
ISO  standards. 

5.  Hierarchical  NSAP  addressing  should  be  used  to  minimize  the  size 
of  routing  tables.  This  conforms  to  criterion  no.  9. 

6.  The  NSAP  address  used  at  the  network  service  interface  is  based 
on  one  and  only  one  subnetwork  point  of  attachment  (SNPA).  This 
makes  the  hierarchial  addressing  more  specific  and  implies  that 
subnetwork  specific  addressing  information  is  embedded  in  the 
NSAP  address. 

7.  The  encoded  network  protocol  address  information  (NPAI)  conveyed 
in  the  IPDU  representing  an  NSAP  address  contains  an  encoded 
subnetwork  address  corresponding  to  the  selected  SNPA.  This 
makes  hierarchical  addressing  more  specific  as  applied  to 
addressing  formats.  The  embedding  of  the  subnetwork  address 
facilitates  routing  and  simplifies  routing  tables. 

8.  The  workshop  participants  require  control  over  the  DSP  encoding 
of  the  NSAP  address. 

9.  NBS  has  obtained  an  IDI  with  value  4 from  ISO  for  OSINET 
so  that  the  AFI  encoding  "47"  may  be  used. 

10.  Optionally,  the  NSAP  addressing  format  should  be  able  to  support 
multiple  network  layer  user  entities  (e.g.,  transport  entities) 
within  one  end  system. 
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11.  All  of  the  above  principles  lead  to  the  address  format  agreed 
upon  and  shown  below. 


47 

ISO 

NBS 

PORTION  OF  DSP  DEFINED 

ASSIGNED 

ASSIGNED  BY  INDIVIDUAL  ORGANIZATION 

ID  I 

ORGANIZATION 

I.D. 

ADDRESSING  AUTHORITIES 

1 

2 

2 

< 11 

Figure  6.4  NSAP  address  format 

12.  If  used  in  the  DSP,  an  NSAP  Selector  field  is  not  used  for 
routing  purposes  nor  for  locating  the  end  system.  It  only 
locates  the  network  layer  user  entity  within  the  end  system 
attached  through  the  addressed  NSAP. 

13.  In  order  to  fulfill  the  criteria  in  section  6.3,  item  3,  a standard 
that  provides  the  functionality  of  dynamic  routing  must  be  provided. 
The  protocol  referenced  under  ISO,  item  #18  "Network  Layer  Management 
Protocol  ..."  provides  for  this  functionality  between  end  and 
intermediate  systems.  This  standard  is  expected  to  be  endorsed 

to  provide  this  function  at  a time  when  it  reaches  a "Draft 
Proposal"  status. 


7.  TRANSPORT 

The  object  of  this  set  of  agreements  is  to  support  the  integration  of 
the  types  of  networks  covered  here  (LANs,  packet  networks,  other  WANs) 
with  the  smallest  possible  set  of  mandatory  protocol  sets,  in  accordance 
with  the  other  agreements  already  reached.  Nothing  here  shall  preclude 
vendors  from  implementing  protocol  suites  in  addition  to  the  ones  described 
in  this  document.  Two  connection  oriented  transport  classes  have  been 
identified  for  implementation  (class  0 and  class  4).  In  addition,  there 
is  interest  among  a limited  set  of  participants  in  implementation  of  a 
connectionless  transport  protocol.  Transport  class  4 (over  CLNP)  has 
been  endorsed  for  general  communication  between  private  systems.  Transport 
class  0 (over  X.25)  is  used  for  communication  with  public  (i.e.  PT&T  and 
RPOA)  MHS  systems  operating  in  accordance  with  the  CCITT  X.400  series 
recommendations.  Communicating  entities  between  private  MIS  systems  over 
an  X.25  network  can,  by  negotiation  or  bilateral  agreement,  agree  to  use 
transport  class  0.  The  connectionless  transport  protocol  can  be  used  with 
transact  ion-type  imp! ementat  ions . 

7.1  TRANSPORT  CLASS  4 

7.1.1  Transport  Class 

The  following  agreement  has  been  reached  with  respect  to  this  protocol. 

Class  4 will  be  used  with  the  required  implementation  of  the  31  bit 
sequence  space  and  16  bit  window  size.  The  full  protocol  will  be  used 
including  expedited  data  and  negotiation  at  connection  establishment. 

These  two  functions  were  not  implemented  for  the  1984  NCC  demonstrations. 
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7.1.2  Protocol  Interpretation 


According  to  the  ISO  transport  specification,  a disconnect  request  is 
issued  in  response  to  a connect  request  when  the  maximum  number  of  transport 
connections  is  reached  or  exceeded. 

7.1.3  Rules  for  Negotiation 


1.  In  general,  the  ISO  rules  for  negotiation  will  be  used,  specifics 
follow. 

2.  All  implementations  will  send  the  16/31  window  size/sequence 
space  in  the  CR  TPDU.  Implementations  must  all  provide  the 
16/31  ISO  option.  Implementations  must  be  able  to  accept  the 
4/7  in  CR  TPDU. 

3.  The  ISO  TPDU  size  is  128  to  8K  octets,  always  negotiated 
downward.  The  ISO  rules  are  to  be  followed,  allowing  any  valid 

size  in  the  CR  TPDU.  TPDU  size  negotiation  is  a local  implementation 
issue.  Each  vendor  will  decide  how  it  is  implemented  in  their 
end  system. 

4.  The  security  parameter  is  optional  and  user  defined  in  the  ISO 
specification.  Implementations  should  not  send  the  security 
parameter  in  the  CR  TPDU;  if  received  it  should  be  ignored. 

5.  Both  transports  must  agree  to  not  use  checksum,  according  to  the 
ISO  specifications.  Requesting  its  use  is  an  implementation 
choice.  All  implementations  must  be  able  to  operate  with  checksum 
if  requested. 

6.  Use  of  acknowledgement  time  parameter  is  optional  in  ISO  8073.  If 

an  implementation  is  operating  any  policy  which  delays  the  transmission 
of  AK  TPDUs,  the  maximum  amount  of  time  by  which  may  single  AK  TPDU  may 
be  delayed  shall  be  indicated  to  the  peer  transport  service  provider 
using  the  acknowledgement  time  parameter.  The  value  transmitted  should 
be  expressed  in  units  of  milliseconds  and  rounded  up  to  the  nearest 
whole  millisecond. 

7.  Throughput,  priority,  and  transit  delay  are  optional  in  the  ISO 
specification.  Do  not  send  in  the  CR  TPDU;  ignore  in  the  CC  TPDU. 

8.  User  data  in  the  CR  TPDU  and  the  CC  TPDU  are  optional.  No 
implementation  should  send;  all  implementations  must  be  prepared 
to  receive. 
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7.1.4  Retransmission  Timer 


It  is  recommended  that  the  value  used  for  the  retransmission  timer 
be  based  upon  the  round-trip  delay  experienced  on  a transport 
connection.  The  implementation  should  maintain,  and  continually 
update,  an  estimate  of  the  round-trip  delay  for  the  TC.  From  this 
estimate,  a value  for  the  retransmission  timer  is  calculated  each 
time  it  is  started.  An  example  technique  for  maintaining  the  estimate 
and  calculating  the  retransmission  timer  is  described  below.  Further 
information  on  similar  techniques  may  be  found  in  the  literature 
[Edge  84,  Jain  85,  Mill  83]. 

The  value  of  the  retransmission  timer  may  be  calculated  according  to 
the  following  formula: 

t^H—  kE  + w 

In  this  formula,  E is  the  current  estimate  of  the  round-trip  delay 
on  the  transport  connection,  w is  the  value  of  the  acknowledgement 
time  parameter  received  from  the  remote  transport  service  provider 
during  connection  establishment,  and  k is  some  locally  administered 
factor . 

A value  for  k should  be  chosen  to  keep  the  retransmission  timer 
sufficiently  small  such  that  lost  TPDUs  will  be  detected  quickly, 
but  not  so  small  that  false  alarms  are  generated  causing  unnecessary 
retransmission. 

The  value  of  E may  be  calculated  using  an  exponentially  weighted 
average  based  upon  regular  sampling  of  the  interval  between  transmitting 
a TPDU  and  receiving  the  corresponding  acknowledgement.  Samples  are 
taken  by  recording  the  time  of  day  when  a TPDU  requiring  acknowledgement 
is  transmitted  and  calculating  the  difference  between  this  and  the 
time  of  day  when  the  corresponding  acknowledgement  is  received.  New 
samples  are  incorporated  with  the  existing  average  according  to  the 
following  formula. 


E*—  E + (1  -<L  )S 

In  this  formula,  S is  the  new  sample  and  alpha  is  a parameter  which  can 
be  set  to  some  value  between  0 and  1.  The  value  chosen  for  alpha  determines 
the  relative  weighting  placed  upon  the  current  estimate  and  the  new 
sample.  A large  value  of  alpha  weights  the  old  estimate  more  heavily 
causing  it  to  respond  only  slowly  to  variations  in  the  round-trip  delay. 
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A small  value  weights  the  new  sample  more  heavily  causing  a quick 
response  to  variations.  (Note  that  setting  alpha  to  1 will  effectively 
disable  the  algorithm  and  result  in  a constant  value  for  E being 
that  of  the  initial  seed.) 

If  alpha  is  set  to  l-2“n  for  some  value  of  n,  the  update  can  be  reduced 
to  a subtract  and  shift  as  shown  below. 

E«4— E + 2 "n(S  - E) 

When  sampling,  if  an  AK  TPDU  is  received  which  acknowledges  multiple 
DT  TPDUs,  only  a single  sample  should  be  taken  being  the  round-trip 
delay  experienced  by  the  most  recently  transmitted  DT  TPDU.  This 
attempts  to  minimise  in  the  sample  any  delay  caused  by  the  remote 
transport  service  provider  withholding  AK  TPDUs. 


7.1.5  Keep-Alive  Function 

The  Class  4 protocol  detects  a failed  transport  connection  by  use  of  an 
'inactivity  timer'.  This  timer  is  reset  each  time  a TPDU  is  received  on 
a connection.  If  the  timer  ever  expires,  the  connection  is  terminated. 

The  Class  4 protocol  maintains  an  idle  connection  by  periodically 
transmitting  an  AK  TPDU  upon  expiration  of  the  'window  timer*.  Thus,  in  a simple 
implementation,  the  interval  of  one  transport  entity's  window  timer  must 
be  less  than  that  of  its  peer's  inactivity  timer,  and  vice  versa.  The 
following  agreements  permit  communicating  transport  entities  to  maintain 
an  idle  connection  without  shared  information  about  timer  values. 

1.  In  accordance  with  ISO  8073,  clause  12. 2. 3. 9. a,  all  implementations 
must  respond  to  the  receipt  of  a duplicate  AK  TPDU  by  transmitting  an 
AK  TPDU  containing  the  'flow  control  confirmation'  parameter. 

2.  Implementations  must  always  transmit  duplicate  AK  TPDUs  on  expiration  of 
the  local  window  timer  (see  ISO  8073,  clause  12.2.3.8.1).  Receipt  of 
this  TPDU  by  the  remote  transport  entity  will  cause  it  to  respond  with 
an  AK  TPDU  containing  the  'flow  control  confirmation'  parameter. 

When  this  is  received  by  the  local  transport  entity,  it  will  reset 
its  inactivity  timer.  See  figure  7.1. 

3.  It  is  a local  matter  for  an  implementation  to  set  the  intervals  of 
its  timers  to  appropriate  relative  values.  Specifically: 

a)  The  window  timer  must  be  greater  than  the  round-trip  delay. 

See  section  7.1.4. 

b)  The  inactivity  timer  must  be  greater  than  two  times  the  window 
timer;  and  should  normally  be  an  even  greater  multiple  if  the 
transport  connection  is  to  be  resilient  to  the  loss  of  an  AK  TPDU. 
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A duplicate  AK  TPDU  (see  Figure  7.1)  is  one  which  contains  the  same  values 
for  YR-TU-NR,  credit,  and  subsequence  number  as  the  previous  AK  TPDU 
transmitted.  A duplicate  AK  TPDU  does  not  acknowledge  any  new  data,  nor 
does  it  change  the  credit  window. 


I W 


reset 


reset 


dupl icate 
AK 

exp  ire 

expire 

dupl icate 
AK 

AK  + FCC 

expire 

Figure  7.1  AK  exchange  on  idle  connection 


7.2  TRANSPORT  CLASS  0 


7.2.1  Transport  Class 

Transport  class  0 over  X.25  is  mandatory  (see  X.400)  for  use  in  communicating 
with  public  MS  systems  operating  in  accordance  with  the  CCITT  X.400  series 
recommendations.  The  purpose  of  the  agreements  concerning  transport 
class  0 is  to  allow  connection  to  these  public  services.  Transport  class 
0 over  X.25  can  also  be  used  in  communicating  between  PRMDs,  but  it  is 
agreed  that  Transport  Class  4 and  CLNP  over  all  types  of  lower  layer 
networks  allows  a larger  range  of  interoperation  and  is  recommended. 
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7.2.2  Protocol  Interpretation 


Transport  class  0 is  a relatively  simple  protocol  providing  little 

opportunity  for  conflicting  interpretations.  A few  relevant  agreements  follow. 

1.  The  Disconnect  Request  (DR)  TPDU  shall  be  limited  to  the  first  seven 
octets  - "LI"  plus  "fixed  part". 

2.  The  Error  (ER)  TPDU  may  be  used  at  any  time  and  upon  receipt  requires 
that  the  recipient  disconnect  the  network  connection  (and  by  extension 
the  transport  connection). 

7.2.3  Rules  for  Negotiation 

1.  The  ISO  rules  for  negotiations  will  be  used. 

7.3  CONNECTIONLESS  TRANPORT 


Document  ISO  IS  8072/DAD1  is  the  Transport  Service  Definition  covering 
Connectionless-mode  Transmission.  Document  ISO  DIS  8602  is  the  Protocol 
for  providing  the  Connectionless-mode  Transport  service. 

8.  SESSION 


Session  services  are  defined  to  meet  the  needs  of  many  applications.  The 
Session  service  is  defined  in  ISO  8326  (CCITT  X.215)  and  the  session 
protocol  is  defined  in  ISO  8327  (CCITT  X.225).  The  general  agreements 
about  the  use  of  session  are  documented  below  in  section  8.1,  followed  by 
agreements  that  are  related  to  specific  applications. 

8.1  GENERAL 

The  services  of  the  Session  kernel  functional  unit  are  used  as  specified 
in  the  standard. 


Session  Connection 
Data  Transfer 
Orderly  Release 
Provider  Abort 
User  Abort 

Basic  concatenation  is  required  by  the  session  protocol  standard.  Extended 
concatenation  is  not  required  and  can  be  refused  using  the  normal  negotation 
mechanisms  provided  by  the  session  protocol. 

Session  segmenting  is  not  required  and  can  be  refused  using  the  normal 
negotiation  mechanisms  of  the  session  protocol. 

Reuse  of  a transport  connection  is  not  required  and  can  be  refused  using 
the  normal  negotiation  mechanisms  of  the  session  protocol. 

The  use  of  transport  expedited  is  as  stated  in  the  session  protocol 
specification.  That  is,  if  transport  expedited  is  available  it  must  be 
used. 

The  maximum  length  of  the  reflect  parameter  values  parameter  in  the  S-P- 
Except  ion-Report  is  1024  octets. 
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The  user  data  parameter  on  S-CONNECT  SPDU  will  allow  unlimited  length 
user  data  as  specified  in  the  proposed  Session  draft  addendum.  This  is 
due  to  the  fact  that  the  combined  P-CONNECT,  A-ASSOCIATE,  and  F-INITI ALIZE 
may  exceed  the  existing  512  byte  limit. 


8.2  SESSION  REQUIREMENTS  FOR  FT AM 

The  phase  2 FTAM  requires  the  following  functional  units  in  addition  to 
those  specified  in  section  8.1. 

Functional  Units  Session  Services 

Duplex  ------ 


Note:  Implementation  of  the  Resynchronize  functional  unit  is  highly 

recommended  since  the  F-CANCEL  service  may  be  ineffective  when 
mapped  to  S-DATA. 

8.3  SESSION  REQUIREMENTS  FOR  MESSAGE  HANDLING 


The  MHS  application  requires  the  following  functional  units  in  addition  to 
those  specified  in  section  8.1. 


Functional  Units 


Exceptions 


Activity  Management 


Half-duplex 


Minor  Synchronize 


Session  Services 

User  Exception  Reporting 
Provider  Exception  Reporting 

Activity  Start 
Activity  Resume 
Activity  End 
Activity  Interrupt 
Activity  Discard 
Please  Tokens 
Give  Tokens 
Give  Control 

Give  Tokens 
Please  Tokens 

Minor  Synchronization  Point 
Give  Tokens 
Please  Tokens 


Note:  Restricted  use  is  made  by  the  RTS  of  the  session  services  implied 

by  functional  units  selected.  Specifically, 

- NO  use  is  made  of  S-TOKEN-GIVE 

- S-PLEASE-TOKENS  only  asks  for  the  data  token. 
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The  following  additional  points  should  be  noted. 


- In  S-CONNECT,  the  Synchron  izat  ionPointSer ial  Number 
should  not  be  present. 

- Format  of  the  Sess  ionConnect ion  ID  is  described  in  Version 
3 of  the  X. 400-Series  Implementor's  Guide. 


9.  SERVICE  ACCESS  POINTS  AND  SELECTORS 
9.1  UPPER  LAYER  AGREEMENTS 


The  following  upper  layer  addressing  agreements  have  been  reached. 

1.  The  combination  of  NSAP  address,  TSAP  selector,  SSAP  selector, 
PSAP  selector  and  PSAP  address  must  be  unique  to  identify  an 
appl  icat ion  entity. 

2.  It  is  implicitly  agreed  that  the  procedure  followed  for  the 
assignment  of  NSAP  addresses  insures  that  they  are  globally 
un ique. 

3.  The  assignment  of  TSAP,  SSAP,  and  PSAP  selectors  is  a local 
end  system  issue  and  the  values  are  administered  locally. 

4.  SSAP  selectors  are  encoded  as  a string  of  octets,  the  meaning 
of  which  is  known  only  to  the  local  system.  The  length  of  the 
string  cannot  exceed  16  octets. 

5.  PSAP  selectors  are  encoded  as  a string  of  octets,  the  meaning 
of  which  is  known  only  to  the  local  system.  The  length  of  the 
string  cannot  exceed  16  octets. 


9.2  TRANSPORT  CLASS  4 SERVICE  ACCESS  POINTS  OR  SELECTORS 


1.  The  existing  encoding  for  TSAP  selectors  in  the  CR  and  CC  TPDU's 
will  be  maintained.  The  TSAP  selector  field  in  these  TPDU's  shall 
be  encoded  as  a variable  length  field,  two  octets  in  length,  and 
will  be  interpreted  as  a bit  string  (not  an  integer). 


9.3.  TRANSPORT  CLASS  0 SERVICE  ACCESS  POINTS 


For  communicating  with  public  MHS  systems.  Section  5 of  X.410  specifies 
the  use  and  format  of  TSAP  identifiers. 
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10.  ISO  FILE  TRANSFER  & ACCESS  MANAGEMENT  PROTOCOL 


The  following  general  agreements  have  been  reached  with  respect  to  this 

protocol . 

1.  FTAM  will  be  implemented  in  at  least  two  phases.  Phase  1 agreements 

are  contained  in  section  10.1  and  are  devised  for  the  MAP2.1  specification. 
Phase  2 agreements  are  contained  in  section  10.2  and  are  devised  at 
the  request  of  the  Corporation  for  Open  Systems  for  1987  product 
impl ementat ions. 

2.  The  phase  1 FTAM  implementation  specification  is  based  on  the  second 
ISO  draft  proposal.  The  phase  2 FTAM  specification  is  based  on  the 
DIS  and  later  will  be  based  on  the  IS. 

10.1  PHASE  1 FTAM  IMPLEMENTATION  SPECIFICATION 

10.1.1  Phase  1 FTAM  Services 


The  following  subset  of  file  transfer  services  has  been  agreed  to. 

F - INITIALIZE 
F - SELECT 
F - OPEN 

F - READ,  F-WRITE 
F - DATA-END 
F - TRANSFER-END 
F - CLOSE 
F - DESELECT 
F - U-ABORT,  F-P-ABORT 
F - TERMINATE 

(The  implementation  of  F-CANCEL  is  optional.) 

Both  F-READ  and  F-WRITE  will  be  implemented.  There  is  at  most  one  F-OPEN 
and  at  most  one  F-READ  or  F-WRITE  per  file  selection;  more  than  one  file 
may  be  selected  sequentially  over  the  lifetime  of  a connection.  A Session 
connection  is  established  at  the  beginning  of  a file  activity  and 
terminated  when  the  file  transfer  connection  is  released. 
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The  following  limited  management  subset  of  services  has  been 
agreed  to. 


F - CREATE 
F - DELETE 
F - READ-ATTRIBUTE 

(Note  that  this  subset  is  complete  with  respect  to  the  ISO  limited  file 
management  functional  unit.) 

The  user  correctable  file  service  and  the  storage  subset  of  the  virtual 
filestore  attribute  group  will  be  implemented. 

10.1.2  Phase  1 File  Attributes 

Phase  1 FT AM  implementations  will  negotiate  for  the  use  of  Storage 
Attributes. 

The  following  file  attribute  agreements  have  been  reached. 

1.  FILENAME 

DP8571  Part  2 Section  11  minimum  range  for  file  name  will  be  supported 
(1-8  characters).  No  maximum  length  or  format  restrictions.  Any 
system  which  does  not  support  extended  file  name  characterist ics  would 
reject  the  (select,  create,  delete)  request  of  such  a file  name. 

File  names  will  consist  of  upper  case  characters  and  numbers.  The 
first  character  of  a filename  may  not  be  a number. 

2.  ACCESS  STRUCTURE  TYPE 

The  access  structure  type  will  be  unstructured.  Flat  and  hierarchical 
are  not  used. 

3.  PRESENTATION  CONTEXT  NAME 

Two  structures  have  been  approved. 

VARCRLF:  Text  format.  Each  line  is  variable  length  and  must  be 

terminated  by  a CRLF  pair.  Line  length  is  limited  to  250 
characters  plus  CRLF.  Form  feed  is  excluded.  CR  and  LF 
cannot  occur  separately.  The  ISO  646  character  set  will  be 
used. 

UNDEF:  Bit  string  encoding.  No  embedded  structure  is  recognized. 

4.  CURRENT  FILESIZE 

Value  represented  as  conformant  with  second  ISO  draft  proposal. 

5.  REQUESTED  ACCESS 

This  attribute  will  support  read,  replace,  read  attribute,  and  delete 

file. 
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6.  CURRENT  ACCESS  STRUCTURE  TYPE 

The  current  access  structure  type  will  be  unstructured. 

7.  CURRENT  PRESENTATION  CONTEXT 

This  attribute  is  the  same  as  PRESENTATION  CONTEXT,  i.e.,  ASCII  or 
binary. 

8.  FUTURE  FILESIZE 

This  is  a provider  option.  Value  represented  as  conformant  with 
second  ISO  draft  proposal. 

9.  DATE  AND  TIME  OF  CREATION 

This  is  a provider  option.  The  value  is  represented  as  conformant  with 
second  ISO  draft  proposal.  Resolution  and  accuracy  are  implementation 
dependent. 

10.1.3  ISO  Deviations  and  Selections 


1.  (DP8571/3  8.1  Table  1)  Implementation  of  the  F-CANCEL  service 
for  non-recoverable  errors  in  the  read  and  write  functional  units 
is  optional.  An  implementation  which  receives  an  F-CANCEL 
indication  may  issue  an  F-ABORT. 

2.  (DP8571/3  8.2  lb)  There  will  be  no  implementation  of  the  grouping 
functional  unit.  The  concatenation  constraint  on  establishing 
and  releasing  a file  open  regime  is  not  supported. 

3.  ( DP8571/3  14.1.2.5)  F-INITIALIZE  The  value  of  the  Service  Type 
parameter  chosen  for  implementation  is  "user  correctable  service". 

4.  (DP8571/3  14.1.2.6)  F-INITIALIZE  The  value  of  the  Service  Class 
parameter  chosen  for  implementation  is  "file  transfer  class". 

5.  (DP8571/3  14.1.2.7)  F-INITIALIZE  The  value  of  the  Functional 

Units  parameter  chosen  for  implementation  is  the  set  "read", 

"write"  and  "limited  file  management". 

6.  (DP8571/3  14.1.2.8)  F-INITIALIZE  The  value  of  the  Attribute  Groups 
parameter  chosen  for  implementation  is  "storage". 

7.  (DP8571/3  14.1.2.9)  F-INITIALIZE  The  value  of  the  Rollback 
Availability  parameter  chosen  for  implementation  is  "no  rollback". 

8.  (DP8571/3  14.1.2.11)  F-INITIALIZE  The  values  of  the  Presentation 
Context  Name  parameter  chosen  for  implementation  are  defined  in 
section  10.1.2  of  this  document. 
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9.  (DP8571/3  17.1.2.2)  F -OPEN  The  values  of  the  Processing  Mode 

parameter  chosen  for  implementation  are  "read"  or  "replace". 

10.  (DP8571/3  17.1.2.3)  F-OPEN  The  Presentation  Context  parameter  must 
be  present  to  indicate  the  context  chosen  for  the  transfer.  (This  is 
due  to  the  lack  of  a presentation  layer  implementation  at  this  time.) 

11.  ( DP8571/3  24.3.)  F-DATA  will  be  encoded  as: 

IDENTIFIER:  context  specific  tag  value  [55] 

Length:  (Length  of  OCTETS) 

Contents:  (octets) 

There  is  an  explicit  F-DATA  PDU  because  of  the  direct  FTAM/Session 
mapping. 

The  ASN.l  definition  of  F-DATA  is: 

F-DATA  request  ::=  data[55]IMPLICIT  OCTETSTRING 

12.  The  ASN.l  type  " IS0646String"  will  be  used  instead  of  ASN.l  type 
"Graphicstring"  in  the  abstract  syntax.  Wherever  "Graphicstring"  is 
specificed  in  the  abstract  syntax,  the  abstract  syntax  is  modified 
to  specify  "IS0646String." 

13.  The  Presentat ionContext  attribute  on  the  SELECT/CREATE  request  is 
restricted  to  a sequence  of  only  one  Presentat ionContextName. 

14.  Presentat ionContextName  parameters  will  be  encoded  as: 

Presentat ionContextName  ::=  [Application  13]  PrintableString. 

15.  The  abstract  syntax  for  F- INITIAL  I ZE  will  be: 

F-INITI ALIZE  request  : :=  SEQUENCE 

protocol  Id  [0]  INTEGER  {isoFTAM  (0)}  , 
versionNumber  [1]  IMPLICIT  SEQUENCE] 
major  INTEGER,  minor  INTEGER}, 

--initially  {major  0,  minor  0} 
serviceType  [2]  INTEGER^ 

reliable  (0),  userCorrectable  (1)  , 
serviceClass  [3]  INTEGER  transfer  (0)  , 
access  (1),  management  (2)f, 
funct  ional Un  its  [4]  BITSTRING{ 

read  (0),  write  (1),  fileAccess  (2), 

1 imitedFil eManagement  (3), 
enhancedF il eManagement  (4), 
grouping  (5),  recovery  (6), 
restartDataTransfer  (7)}  , 
attributeGroups  [5]  BITSTRINg) 
storage  (0),  security  (1)}, 
rol 1 backAva il ab il  ity  [6]  BOOLEAN  DEFAULT  FALSE 
ident ityOf In  it iator  [7]  Graphicstring  OPTIONAL, 

CurrentAccount  OPTIONAL, 
f ilestorePassword  [8]  OCTETSTRING  OPTIONAL, 
checkpointWindow  [9]  INTEGER  OPTIONAL, 
presentat ionContextNames  [10]  IMPLICIT 

SEQUENCE  OF  Presentat ionContextName  OPTIONAL 
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F- INITIALIZE  response  ::=  SEQUENCE 


D iagnost  ic , 

protocol  ID  [0]  INTEGER  {isoFTAM  (0)} 
vers ionNumber  [1]  IMPLICIT  SEQUENCE] 
major  INTEGER,  minor  INTEGER}. 

— initially  {major  0.  minor  0} 
serviceType  [2]  INTEGER] 

reliable  (0),  userCorrectable  (1)}, 
serviceClass  [3]  INTEGER  {transfer  (0), 
access  (1),  management  (2)}, 
funct  ional Un  its  [4]  BITSTRING  ] 

read  (0),  write  (1),  fileAccess  (2), 

1 imitedF il eManagement  (3), 
enhancedFileManagement  (4), 
grouping  (5),  recovery  (6), 
restartDataTransfer  (7)(, 
att ributeGroups  [5]  BITSTRING] 
storage  (0),  security  (1)[ 
rol IbackAvailabil ity  [6]  BOOLEAN  DEFAULT  FALSE, 
checkpointWindow  [7]  INTEGER  OPTIONAL, 
presentat ionContextNames  [8]  IMPLICIT 

SEQUENCE  OF  Presentat  ionContextName  OPTIONAL} 


16.  The  Presentat ionContextName  parameter  on  the  F-INITIALIZE  request 
and  response  will  be  a sequence  of  presentation  context  names.  The 
corrected  abstract  syntax  for  this  parameter  will  be: 

Presentat ionContextNames  [10]  IMPLICIT  SEQUENCE  OF 

Presentat  ionContextName  OPTIONAL , 

The  value  of  this  parameter,  if  present,  will  establish  limits  for  the 
life  of  the  FTAM  association. 

17.  The  Presentat ionContextName  parameter  on  the  F-OPEN  request  and  F-OPEN 
response  will  be  mandatory  instead  of  optional. 

18.  Phase  1 FTAM  products  will  use  the  state  machine  in  the  FTAM  second  ISO 
draft  proposal  part  4,  except  where  explicitly  specified  differently  in  these 
agreements . 


10.1.4  Further  Implementation  Details 

The  following  recommendations  are  not  specified  by  the  standard  but  are 
required  to  be  agreed  upon  in  order  to  insure  that  different  implementations 
work  together  smoothly. 
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1.  The  FTAM  implementation  is  mapped  directly  to  Session  services  and 
does  not  incorporate  the  use  of  CASE  at  this  time.  The  F-INITIALIZE 
request  is  embedded  in  the  S-CONNECT  request  and  the  F-INITIALIZE 
response  is  embedded  in  the  S-CONNECT  response,  not  sent  as  an  S-DATA 
request  after  the  Session  has  been  established. 

If  the  F-INITIALIZE  response  is  a positive  confirmation,  the  F-INITIALIZE 
response  is  mapped  onto  S-ACCEPT.  Otherwise,  is  is  mapped  onto  S-REFUSE. 

2.  F-U-ABORT  and  F-P-ABORT  are  mapped  to  S-DATA  requests.  The  receiver 
of  an  F-U-ABORT  or  an  F-P-ABORT  must  issue  an  S-U-ABORT  request. 

This  is  due  to  a possible  S-RELEASE  collison  should  both  entries 
wish  to  abort  simultaneously. 

3.  Implementations  should  be  able  to  parse  all  valid  second  ISO  draft  proposal 
optional  parameters  if  they  are  present  in  the  PDU.  Only  those  optional 
parameters  specified  in  the  agreements  are  required  to  be  supported 

for  request  and  response  PDUs. 

4.  All  second  ISO  draft  proposal  optional  parameters  identified  in  these  agree- 
ments as  mandatory  must  be  supported.  If  these  parameters  are  not  present, 
their  semantics  are  a local  issue  and,  further,  the  request  should  not  be  refused. 

5.  Error  Handling  and  Diagnostic 

Action  that  is  permitted  by  the  standard  is  not  restricted  in  this 
implementation.  Implementations  may  return  a response  with  a negative 
diagnostic  or  issue  an  F-U-ABORT  request. 

6.  Rollback 


"No  rollback"  implies  that  in  case  of  failure,  the  status  of  the 
involved  files  is  unpredictable,  i.e.,  the  parties  may  choose,  in 
their  implementations,  if  they  want  to  leave  as  is  the  partially 
transferred  file  or  cancel  it. 

However,  in  order  to  avoid  dangling  conditions,  after  a failure  (i.e., 
after  an  F-U-ABORT  or  F-P-ABORT)  it  is  recommended,  whatever  the  choice, 
to  always  put  the  files  in  a status  which  does  not  prevent  further 
access  both  from  remote  and  local  systems. 

7.  Concurrency 

No  concurrency  rules  are  adopted  since  the  file  attributes  governing 
them  will  not  be  supported.  Therefore,  each  implementation  may 
choose  the  degree  of  concurrency  on  the  local  files,  as  a local 
matter.  However,  in  order  to  minimize  possible  source  of  errors, 
the  following  implementation  rules  are  recommended. 

a.  A file  may  be  involved  in  several  transfers  simultaneously 
only  if  accessed  in  reading  mode. 

b.  If  a file  is  involved  in  a transfer  in  writing  mode,  any 
other  request  of  access  to  that  file  (either  for  Read  or 
Write)  should  be  rejected. 
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c.  A file  cannot  be  modified  by  local  users  while  it  is  involved 
in  a transfer  operation  (either  in  Read  or  Write).  (As  a 
practical  matter,  this  may  be  very  difficult  to  implement, 
regardless  of  the  protection  mechanisms  provided  by  the 
local  operating  system.) 

8.  The  ISO  ASN.l  sytax  will  be  used  for  encoding  of  PDU  headers. 

9.  The  indefinite  length  style  of  ASN.l  encoding  is  not  supported. 

10.  The  maximum  PDU  length  is  1024  octets. 

11.  If  a read  attribute  request  specifies  an  NBS  optional  attribute  that  is  not 
supported  by  an  implementation's  virtual  filestore,  then  that  attribute 
will  not  be  returned  in  the  Read  Attribute  response.  It  is  recommended 
that  an  implementation  return  an  appropriate  diagnostic  in  this 
situation  (e.g.,  400,  "attribute  non-existent"). 

12.  In  the  FTAM  second  ISO  draft  proposal,  the  parameter  DIAGNOSTIC  is  defined 
as  an  implicit  sequence  of  diagnostics.  The  order  of  the  diagnostics  is 
arbitrary  and  has  no  significance. 

13.  If  a Responder  receives  an  S-CONNECT  indication,  and  the  user  data 
carried  on  that  indication  are  "corrupted"  (i.e.,  decoding  the  PCI 
results  in  an  unrecoverable  error),  then 

1)  If  the  user  data  can  be  identified  as  an  F-INITIALIZE  request, 
the  Responder  should  respond  with  an  F-INITIALIZE  response  (-) 
or  F-P-ABORT  with  diagnostic  conveying  an  unrecoverable  error. 

This  is  to  be  carried  on  an  S-CONNECT  response  (-)  (i.e., 
rejecting  the  connection). 

The  Responder  should  further  clarify  the  error  in  "further  details 
field  of  diagnostic". 

Parameters  on  the  F-INITIALIZE  response  should  be  reflected  where 
appropriate;  where  this  is  not  possible,  default  values  should 
be  chosen  by  the  Responder  where  mandatory  parameters  are 
required  and  cannot  be  reflected. 

2)  If  the  user  data  cannot  be  identified  as  an  F-INITIALIZE  request, 
the  Responder  should  respond  with  an  S-U-ABORT  with  reason  code 
appropriate  to  the  error. 

10.2  PHASE  2 FTAM  IMPLEMENTATION  SPECIFICATION 


10.2.1  Assumpt ions 

1.  Implementations  will  be  based  on  the  ISO  8571  DIS  version  of  FTAM. 

When  the  IS  text  is  approved  following  the  close  of  DIS  ballots  the 
agreements  will  be  modified  as  necessary  to  meet  the  IS  specifications. 
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2. 


FTAM  Protocol  machines  must  be  able  to  parse  and  process  up  to  7K 
octets  of  File  PCI  and  FTAM  user  data  (including  grouped  FPDUs)  as 
they  would  be  encoded  with  the  ASN.l  Basic  Encoding  Rules.  It  is 
recommended,  however,  that  Presentation  user  data  not  be  restricted 
in  size. 

3.  In  order  to  maximize  interoperab il  ity  it  is  important  for  implementations 
of  FTAM  service  providers  not  to  restrict  unnecessarily  the  service 
user's  ability  to  generate  arbitrary  file  service  requests,  as  otherwise 
they  may  not  be  able  to  work  with  FTAM  Responders  whose  operation  is 
constrained  by  their  mapping  of  the  FTAM  virtual  filestore  to  their 
local  filestore.  For  example,  error  procedures  should  only  be  invoked 

at  the  actual  occurence  of  an  error,  not  at  the  specification  of  options 
which  might  result  in  an  error. 

4.  Implementations  should  be  able  to  parse  all  valid  DIS  optional  parameters 
if  they  are  present  in  the  PDU.  Only  those  optional  parameters 
specified  as  mandatory  in  these  agreements  are  required  to  be  supported 
for  request  and  response  PDUs.  If  these  parameters  are  not  present, 

it  is  a local  implementation  issue  to  assign  a default  value.  A 
request  should  not  be  refused  if  a parameter  which  is  optional  in  the 
FTAM  standard,  but  is  mandatory  in  these  agreements,  is  not  present. 

5.  Consideration  of  any  standarized  service  interface  is  outside  the 
current  work  items  of  the  FTAM  SIG. 

10.2.2  Presentation  Agreements 

The  following  Abstract  Syntaxes  are  supported: 

- ISO  8571-FTAM 

- ISO  8571-FADU 

- ISO  8650-ACSE1 

- NBS-AS1 

- NBS-AS2 

- NBS-AS3 

A registration  mechanism  will  be  determined  to  provide  registered  names 
for  these  syntaxes. 

If  the  presentation  context  management  functional  unit  is  available,  it  is 
possible  to  use  P-ALTER-CONTEXT  to  negotiate  the  use  of  an  abstract  syntax. 
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10.2.3  FTAM  Service  Type  Agreements 


The  user  correctable  service  level  (excluding  Recovery  and  RestartDataTransfer 
functional  units)  will  be  implemented.  There  is  no  requirement  to  implement 
the  error  recovery  protocol  machine. 

10.2.4  Service  Class  Agreements 

Implementation  of  the  following  service  classes  is  defined. 

- File  Transfer 

- File  Access 
-File  Management 

- File  Transfer  and  Management 

- Unconstrained 

10.2.5  Functional  Unit  Agreements 

Implementation  of  the  following  functional  units  is  defined. 

- Kernel 

- Read 

- Write 

- File  Access 

- Limited  File  Management 

- Enhanced  File  Management 

- Grouping 


10.2.6  File  Attribute  Agreements 

1.  A value  for  file  name  and  contents  type  will  always  be  available. 

Only  the  kernel  group  of  attributes  is  required. 

2.  Requests  for  an  attribute  value  shall  always  return  one  of  the 
fol  1 owing: 

(a)  An  actual  file  attribute  value. 

(b)  A value  indicating  that  the  attribute  value  is  not  available 

at  this  time.  Optionally  a diagnostic  may  be  provided  indicating 
that  the  attribute  is  not  supported. 

The  set  of  file  management-related  diagnostics  will  be  maintained. 

3.  If  the  optional  Storage  Group  is  implemented,  the  following  attribute 
must  have  an  actual  value  available: 

- Permitted  Actions. 

4.  If  the  optional  Security  Group  is  implemented,  the  following  attribute 
must  have  an  actual  value  available: 

- Access  Control . 
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5.  Implementation  of  the  private  group  is  not  specified. 

6.  Contents  Type  attribute  is  limited  to  the  Document  Type  Name  form. 

7.  A minimum  range  for  filename  values  is  required  (1-8  characters).  No 
maximum  length  or  format  restrictions  apply.  A system  which  does  not 
support  multi-component  filenames  or  extended  filename  characteristics 
may  reject  a request  involving  such  a filename.  All  systems  must  be 
able  to  interpret  single  component  filenames.  Requests  using  single 
component  filenames  will  be  responded  to  using  single  component  filenames. 
Responses  to  requests  involving  two  or  more  component  filenames  are  not 
defined  here  but  may  be  interpreted  via  bilateral  or  other  external 
agreement.  Use  of  filenames  with  multiple  components  is  discouraged. 

10.2.7  Document  Type  Agreements 

The  following  document  types  are  defined. 

NBS-1  UNDEF 
NBS-2  VARCRLF 
NBS-3  8859VARCRLF 
NBS-4  TEXT 
NBS-5  8859TEXT 
NBS-6  SEQUENTIAL 
NBS-7  RANDOM 
NBS-8  INDEXED 
NBS-9  FILE_DIRECTORY 

Part  of  the  ongoing  work  of  the  FTAM  SIG  is  to  define,  discuss  and  incorporate 
other  file  types.  Detailed  document  type  definitions  are  given  in 
APPENDIX  D. 

Document  type  Names: 

« DTN  ::=  DTName  | DTName  pa rams 
DTName  ::=  OBJECT  IDENTIFIER 
params  ::=:param  | rparam  params 
param  ::=  Primtype  | PrimType,  param 

PrimType  :=  I NT  - <n*> 

BIT  - <n2> 

IA5  - <nl> 

8859  - <nl> 

OCT  - <nl> 

UTC 

GEN 

NULL 

BOOL 

FLOAT  - <n3,  n4> 
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<nl>  - Maximum  number  of  characters/octets  in  string. 

<n2>  - Number  of  bits  in  string  (i.e.,  nonvarying). 

<n3>  - The  minimum  number  of  bits  required  to  be  mantissa 
for  relative  precision. 

<n4>  - Number  of  bits  required  to  represent  unbiased  integer  exponent. 

<n*>  - Number  of  octets  required  to  represent  in  2's  complement  format 
the  largest  integer  to  be  passed. 

The  primitive  data  types  and  minimal  size  range  which  an  implementation 
must  accept  are  given  in  the  following  table. 


Table  10.1  FTAM  primitive  data  types 


PRIMITIVE  DATA  TYPE 

REPRESENTATION 

MINIMUM  RANGE  (OCTETS) 

IN  PARAMETER 

ASN.l 

INTEGER 

INT  <N*> 

(1 

- 2) 

ASN.l 

Bit  String 

BIT  <N2> 

(0 

- 1) 

ASN.l 

IA5String 

IA5  <N1> 

(0 

- 134) 

NBS-AS1 

8859String 

8859  <N1> 

(0 

- 134) 

ASN.l 

OCTETSTRING 

OCT  <N1> 

(0 

- 512) 

ASN.l 

BOOLEAN 

BOOL 

ASN.l 

NULL 

NULL 

ASN.l 

General ized  T ime 

GEN 

ASN.l 

Universal  Time 

UTC 

NBS-AS1 

Floating  Point 

FLOAT  <N3 ,N4> 

Note : 

The  primitive  data  types  and  their  maximum 

ranges  for  a 

specific 

file  as  described 

by  the  parameters  above  are  maintained 

in  the 

contents  type  file 

attribute.  The  contents 

type  file  attribute 

value  is  established  at  the  file's  creation 

and  cannot  be  changed 

via  FTAM  for  the  life  of  the  file.  This  implies  that  the  data 

element  types  and 

ranges  and  data  unit  formats  are  fixed 

for  all 

accessors  of  that  file  as  long  as  the  file  exists. 

An  object  identifier  is  a string  of  integers;  FTAM  document  type 
parameterization  will  be  achieved  by  exploiting  that  structure. 

The  final  registration  authority  entity  will  be  followed  by  a data  unit 
description.  The  data  unit  description  is  a series  of  data  element 
descriptions.  Each  data  element  description  is  an  integer  identical  to  the 
ASN.l  type  code,  followed  by  any  required  parameter  values  (as  integers). 

The  following  values  correspond  to  the  NBS  primitives  not  found  in  ASN.l 
and  the  integer  value  for  (separator). 

FLOAT  - 127 
8859  - 126 
: - 125 
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The  following  abstract  syntax  definition  is  given  for  the  respresentat ion 
of  floating  point  numbers.  The  ability  to  transfer  floating  point  numbers 
is  not  required.  The  only  semantics  associated  with  the  floating  point 
primitive  type  is  its  use  to  convey  a value  of  relative  precision. 

The  following  notation  is  believed  to  allow  the  movement  of  the  same 
semantics  as  existing  standards  for  floating-point  numbers  (IEC  559  and 
IEEE  754)  as  well  as  represent  an  infinite  number  of  binary  floating  point 
numbers. 

Float ingPointNumber  ::=  [PRIVATE  0]  CHOICE 
finite  [0]  IMPLICIT  SEQUENCE 


Sign , 

mantissa  BIT  STRING, 
exponent  INTEGER 


inf  in  ity 

[1] 

IMPLICIT  Sign, 

s ignal  1 ingNaN 

[2] 

IMPLICIT  NaN, 

quiteNaN 

[3] 

IMPLICIT  NaN, , 

zero 

[4] 

IMPLICIT  NULL f 

Sign 

1 

INTEGER 

pos it ive 

(0) 

negat  ive 
> 

(1) 

NaN 

: := 

INTEGER 

Notes:  1.  The  mantissa  is  a number  in  the  range  1/2  <_  mantissa  < 1. 

2.  Mantissa  * 2 exponent # 

3.  The  first  bit  in  the  mantissa  is  most  significant. 

4.  See  IEEE  754  for  definitions  of  terminology  such  as  NaN. 

10.2.7.1  Character  Sets 


The  character  sets  IA5  and  8859/1  have  been  specified  for  use.  The  following 
describe  how  each  of  the  character  sets  will  be  implemented. 

1.  IA5 

The  IA5  character  set  leaves  2 options  and  10  characters  unspecified. 

The  following  definitions  will  be  used. 


2/3  # 

2/4  $ 

4/0  0 

5/11  [ 

5/12  \ 

5/13  ] 


5/14 

6/0 

7/11 

7/12 

7/13 

7/14 
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(Note  this  is  exactly  the  International  Reference  Version  (IRV)  specified 

in  the  IA5  standard  except  that  the  code  2/4  has  the  graphic  rendition  "$" 

instead  of  the  IRV-specif ied  value  of  "x") 

The  following  details  how  control  characters  should  be  handled. 

a)  The  semantics  of  format  effectors  will  be  preserved. 

b)  Transmission  control  characters,  device  control  characters,  information 
separators,  and  "other"  control  characters  will  simply  be  preserved  via 
their  codes. 

c)  Code  extension  should  not  be  used.  If  it  is,  the  code  extension 
characters  should  be  preserved  as  in  the  case  of  the  transmission 
control  characters  and  any  printing  characters  that  form  later  parts 
of  escape  sequences  will  be  interpreted  as  stand  alone  characters. 

d)  Combined  horizontal  and  vertcal  movement  of  cursor  positioning  will 
not  be  preserved. 


2.  8859/1 

The  Latin  Alphabet  No.  1 will  be  used  to  specify  the  printable  rendition 
of  CO  and  Cl. 

The  CO  control  characters  and  their  associated  rules  will  be  taken  from  the 
IA5  definition. 

The  Cl  control  characters  will  simply  have  their  codes  preserved  across 
a transfer. 


10.2.7.2  Document  Type  Negotiation  Rules 


1 . Connection  Establishment: 

DocumentTypeNames  are  to  be  negotiated  by  subset  (of  the  proposed  base 
DocumentTypeNames)  without  regard  to  DU  syntax  parameter(s)  that  may  be 
supplied  on  any  DocumentTypeNames  which  require  a DU  syntax  specification. 

2.  File  Creation: 

An  F-CREATErequest  must  contain  a DocumentTypeName  from  the  negotiated  set 
of  base  DocumentTypeNames.  If  the  DocumentTypeName  being  used  requires  DU 
syntax  parameters,  then  these  parameters  must  be  supplied.  If  the 
DocumentTypeName  being  used  requires  DU  syntax  parameters  and  none  are 
provided  on  the  F-CREATErequest,  then  the  F-CREATErequest  must  be  rejected. 

3.  File  Opening: 

It  is  recommended  that  the  F_0PENrequest  use  the  DocumentTypeName  form 
(with  appropriate  DU  syntax  parameters),  when  proposing  a Contents  Type,  in 
preference  to  the  Constraint  Set  Name  and  Abstract  Syntax  Name  form. 
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Similarly,  an  F_OPENresponse  should  use  the  DocumentTypeName  option  (with 
appropriate  DU  syntax  parameters)  in  the  Contents  Type  field.  This  will 
allow  the  receiving  entity  to  use  the  DocumentTypeName  attributed  to  the 
file  instead  of  receiving  a Constraint  Set  Name  and  Abstract  Syntax  Name 
pair  which  does  not  reflect  the  file  information  contained  in  the  NBS 
document  types. 

NOTE:  An  F_OPENresponse  without  a DocumentTypeName  (but  carrying  the 

Constraint  Set  Name  and  Abstract  Syntax  name  form  may  cause  the  initiator 
to  issue  an  F_CL0SE request. 


10.2.7.3  Relationship  Between  DUs,  DEs  and  Document  Types 

"Abstract  Syntax"  is  used  to  refer  to  the  syntactic  information  which  is 
arch itecturally  passed  between  the  Application  and  Presentation  layers. 

The  Abstract  Syntax  defines  data  element  (DE)  types.  The  DE  types  are  not 
necessarily  ASN.l  primitive  types.  Data  types  may  be  made  up  of  other  data 
types.  Data  Elements  are  not  defined  in  terms  of  other  data  elements. 

A data  unit  (DU)  is  a sequence  of  one  or  more  data  elements.  Architecturally, 
entire,  single  DEs  are  passed  into  and  out  of  the  application  process.  In 
a real  implementation,  DUs  may  be  passed. 

In  order  to  maintain  DU  boundaries  during  transfer,  file  structuring 
information  must  be  passed  ( IS08571-FADU  DEFINITIONS,  FTAM  Part  2 
section  5.3.2).  A data  element  is  referred  to  as  a File  Contents  Data 
Element  in  IS08571-FADU  DEFINITIONS. 

Document  types  refer  to  aspects  of  local  processing  and  storage.  Document 
types  describe: 

1)  structural  relationship  between  DUs, 

2)  structure  of  DUs,  called  DU  syntax,  and 

3)  data  element  types  found  in  the  file. 

Because  document  types  have  to  do  with  local  processing  and  storage,  the  DU 
syntax  makes  assertions  about  the  syntax,  and  size  of  DUs  (records)  in 
storage.  Parameters  on  the  document  types  provide  this  information  about 
the  syntax  and  size  of  the  DUs. 


10.2.8  F-CANCEL  Action 


When  an  F-CANCEL  is  sent  or  received,  the  following  will  occur: 

- no  more  data  will  be  sent 

- check  point  numbers  are  removed 

- state  of  the  file  will  be  implementation  dependent. 
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10.2.9  Error  Handl  ing  Agreements 


1.  Diagnostic  is  mandatory  only  when  the  Action  Result  or  State  Result  is 
not  zero. 

2.  General  catch-all  diagnostic  is  discouraged. 

3.  Further  details  subfield  is  mandatory.  Use  of  octet  string  is  discouraged. 

4.  Use  of  F-P-ABORT  for  other  than  protocol  errors  and  catastrophic  situations 
is  discouraged. 

5.  When  returning  an  error  status  in  a file  management  related  diagnostic 
(i.e.,  F-READ-ATTRIBUTE-response  or  F-CHANGE-ATTRIBUTE-response) , 
identify  the  erroneous  attribute  by  using  the  first  two  characters  of 
Diagnostic  further-details  to  hold  a 2-digit  number  (encoded  in  IA5) 
from  the  F-READ-ATTRIBUTE-request  attributes  abstract  syntax  definition 
( I SO/D  IS  8571/4  section  20-4): 

00  F i 1 en  ame 

01  Contents-Type 

02  Storage  Account 

03  Date  and  Time  of  Creation 

04  Date  and  Time  of  Last  Modification 

05  Date  and  Time  of  Last  Read  Access 

06  Date  and  Time  of  Last  Attribute  Modification 

07  Identity  of  Creator 

08  Identity  of  Last  Modifier 

09  Identity  of  Last  Reader 

10  Identity  of  Last  Attribute  Modifier 

11  File  Availabil  ity 

12  Permitted  Actions 

13  Filesize 

14  Future  Filesize 

15  Access  Control 

16  Encryption  Name 

17  Legal  Qualifications 

18  Private  Use 


10.2.10  Concurrency 

The  concurrency  control  used  by  default  for  the  first  accessor  of  a file 
is: 


read 

shared 

insert 

exclus ive 

repl ace 

exclusive 

extend 

exclus ive 

erase 

exclusive 

rattr 

shared 

cattr 

exclusive 

del  file 

exclus  ive 

e accessors. 

the  requested  access  and  processing  mode 

request  is  for  operations  that  are  shared. 
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10.2.11  Security 

1.  Users  may  provide  "user  Id"  (Initiator  Identity)  and  "password"  (filestore 
password).  If  the  information  is  provided,  the  information  will  be  sent  to  the 
Responder  on  the  F-INITIALIZE. 

2.  Users  may  provide  "access  passwords".  If  the  information  is  provided, 

the  passwords  will  be  sent  to  the  Responder  in  the  "access  passwords"  parameter. 

3.  It  is  the  responsibility  of  each  local  system  to  provide  security  of 
its  own  real  file  store. 

4.  The  syntax  of  "user  Id"  and  "password"  (filestore  password)  is  system-dependent. 

5.  Encryption  of  passwords  will  not  be  done  by  FTAM. 

6.  "User  Id"  and  "password"  will  represent  'account'  information  (this  may 
be  different  from  the  'account'  parameter). 

7.  A user  of  the  file  service  must  be  known  by  the  Responder. 

8.  A commonly  defined  "anonymous  user"  convention  will  be  provided  for  all 
systems  that  choose  to  support  this  capability.  Access  available  to 
that  user  is  locally  determined.  The  ID  to  be  used  is  ANON.  Any 
password  should  succeed. 

9.  Password  support  in  FTAM  is  not  required. 


10.2.12  Negot iat  ion 

The  guidelines  for  negotiation  in  the  following  table  have  been  agreed. 


Table  10.2  FTAM  negotiation  rules 


Service  or  Parameter 


Depends  on  or  may  be  negotiated 
down  by 


F-INITIALIZE 


Req. Pres. Con textMgmt 
Req.Func.  Units 


Success  or  failure. 
Negotiated  by  subset. 


Req.Attr.  Groups 
Req. Comm. Qual ity 


(Affects  session  functional  units.) 
Negotiated  by  subset. 


of  services 
Req.ContentTypeL ist 


Reference  session. 
Negotiated  by  subset. 


F-SELECT 


Attributes 


Only  by  filename. 

N.B.  the  filename  on 
response  and  confirm 
must  be  that  of  an  existing 
virtual  file. 
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Requested  Access 

Negotiated  by  subset  (in  case  of 
complete  or  partial  success),  must 
be  consistent  with  Functional  Units 
negotiated,  access  control  attribute 
and  permitted  actions  attribute. 

F-CREATE 

Consistent  with  Functional  Units. 

Initial  attributes 

* 

1)  The  attributes  returned  are  within 
the  subset  negotiated  at  initialization 

2)  The  individual  attribute  values 
returned  must  be  consistent  with 
negotiation/ranges  for  that  attribute. 

3)  The  Responder  returns  values  for  all 
attributes  which  differ  from  the  actual 
request. 

Requested  Access 

as  in  F-SELECT 

F-DELETE 

Consistent  with  Functional  Units. 

F-READ-ATTR 

Consistent  with  Functional  Units, 
service  class  and  requested  access. 

F-CH ANGE-ATTR 

as  for  F-READ-ATTR IBUTE 

Attributes 

If  any  attribute  cannot  be 
successfully  changed,  then  an  error 
more  severe  than  warning  should 
be  returned  and  no  attribute 
should  be  changed. 

F-OPEN 


Processing  Mode 

Not  Negotiated. 

Must  be  consistent  with  Functional  Unit 
and  Requested  Access  negotiated,  with 
the  permitted  actions  attribute 
and  the  contents  type  name. 

Contents  Type 

Defined  in  DIS. 

Concurrency  Control 

More  restrictive  than  concurrency 
control  of  F-SELECT;  consistent 
with  the  concurrency  control  of 
other  users. 

”f-begin-group| 
F-END-GROUP  J 

Consistent  with  Functional  Units  and  * 
service  class. 

f-locate] 

F-ERASE  J 

Consistent  with  Functional  Units, 
requested  access  (and  therefore  also 
permitted  actions).  Service  Class  and 
Processing  Mode 
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Functional  Units,  Service  Class  and 
number  of  bulk  data  transfers, 
Requested  Access  and  Processing  Mode. 


F-READ 

F-WRITE 


F-DATA/F-DATA-END 

F-CANCEL 

F-TRANSFER-END 


Functional  Units  and 
Service  Cl  ass. 


10.2.13  Presentation  Context  Negotiation 


After  successful  negotiation  of  a presentation  context  between  two  applications, 
a presentation  context,  i.e.  a pair  of  (abstract  syntax,  transfer  syntax),  has 
been  agreed  between  the  application  and  presentation  entities.  The  transfer 
syntax  may  have  a wider  range  than  the  associated  abstract  syntax,  i.e.,  it 
may  also  encode  data  types  not  contained  in  that  abstract  syntax. 

The  understanding  (for  the  Implementors  Agreements)  is  that  for  that 
specific  application  association  the  transfer  syntax  is  restricted  to  the 
abstract  syntax.  That  means  encodings  of  data  types  not  contained  in  the 
negotiated  abstract  syntax  may  be  rejected  by  the  receiving  presentation 
ent  ity. 


10.2.13.1  Steps  of  Presentation  Context  Negotiation 

There  are  four  entities  involved  in  the  negotiation  of  a Presentation 
Context,  two  Application  Entities,  and  two  Presentation  Entities.  The 
relationship  among  the  entities  is  as  shown  in  the  figure  below: 


Appl icat  ion 

AE1 

1 

AE2 

1 

Presentat ion 

i 

”"T"” 

PEI 

I 

PE2 

Lower  Layers 

— c 

) — 

**'i 

Figure  10.1  Relationship  among  entities 


AE1  - Application  Entity  1 - needs  an  additional  abstract  syntax 

AE2  - Application  Entity  2 

PEI  - Presentation  Entity  on  AEl's  node 

PE2  - Presentation  Entity  on  AE2's  node 
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Once  AE  1 determines  that  it  has  a need  to  use  an  additional  abstract 
syntax,  there  are  seven  steps  in  the  negotiation  of  a Presentation  Context. 
They  are: 

1)  AE1  informs  PEI  that  it  needs  a new  abstract  syntax,  say  AS1. 

2)  PEI  picks  a favorite  transfer  syntax,  or  set  of  transfer  syntaxes, 
that  can  encode  AS1,  say  TS1. 

3)  PEI  asks  PE2  if  it  can  deal  with  TS1.  It  does  this  by  sending  the 
pair  (AS1,TS1)  to  PE2  along  with  an  identifier  for  the  Presentation 
Context . 

4)  PE2  decides  if  it  can  handle  the  transfer  syntax  TS1.  If  it  can,  it 
informs  AE2  that  there  has  been  a request  to  use  AS1. 

5)  AE2  decides  if  it  can  handle  AS1,  and  informs  PE2. 

6)  If  PE2  has  accepted  TS1  and  AE2  has  accepted  AS1  then  PE2  informs 
PEI  that  the  Presentation  Context  has  been  accepted.  If  either  TS1 

or  AS1  has  been  rejected,  PE2  informs  PEI  that  the  Presentation  Context 
has  been  rejected. 

7)  PEI  tells  AE1  whether  AS1  has  been  accepted  or  rejected. 


10.2.14  Conformance 

The  FTAM  SIG  in  cooperation  with  the  COS  FTAM  Technical  Committee  will  propose 
a revised  conformance  statement  for  the  next  version  of  these  agreements. 


10.2.15  Migration  Strategy 


NBS  Phase  2 FTAM: 

There  is  no  backward  compatibility  with  NBS  FTAM  Phase  1.  The  following 
examples  provide  some  of  the  technical  clarifications  as  to  why  this  backward 
compatibility  is  impossible: 

Phase  1 Phase  2 

Uses  Session  directly  Uses  CASE  services 

Uses  Presentation  Services 

Filestore  differences 

PDU  Abstract  syntax  differences 

FADU  Structuring  abstract  syntax  differences 

Transfer  syntax  differences 

Transparency  mechanism  differences 

Service  Class  Negotiation  differences 

NBS  FTAM  Future  Phases: 

Given  that  FTAM  Phase  2 is  based  on  the  forthcoming  FTAM  IS  and  that  this  IS 
will  provide  the  ability  to  pass  "user  version"  information  and  will  provide 
backward  compatibility  of  protocol  between  versions  of  the  IS,  the  workshop 
will  specify  mechanisms  to  provide  FTAM  product  backward  compatibility  for 
one  previous  product  version  (i.e.,  NBS  Phase). 
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11.  ISO  PRESENTATION  LAYER  PROTOCOL 


Presentation  Services  are  defined  to  meet  the  needs  of  many  applications. 
The  Presentation  service  is  defined  in  ISO  DIS  8822  and  the  Presentation 
protocol  is  defined  in  ISO  DIS  8823.  The  general  agreements  about  the 
implementation  of  Presentation  are  documented  below. 


11.1  General 

1)  Implementations  will  be  based  on  the  DIS  (to  be  replaced  by  the  IS) 
version  of  the  ISO  Presentation  service  and  protocol. 

2)  A conformant  implementation  must  be  conformant  to  the  ISO  Presentation 
service  and  protocol,  and  must  meet  all  of  the  requirements  of  this 
specif icat  ion . 


11.2  Functional  Units 

1)  The  following  functional  units  are  mandatory  for  implementation. 
- Kernel 

2)  Implementation  of  any  other  functional  unit  is  optional. 


11.3  Abstract  Syntaxes 

1)  The  following  abstract  syntaxes  must  be  supported. 


- ISO  8571-FTAM 

- ISO  8571-FADU 

- ISO  8650-2-ACSE1 

- NBS-AS1 


(FTAM  PCI) 

(File  Structuring) 
(CASE  PCI) 

(Primitive  data  types) 


2)  The  following  abstract  syntaxes  are  defined  in  these  agreements,  but 
are  optional. 


- NBS-AS2 

- NBS-AS3 


(floating  point  numbers) 
(file  directories) 


3)  Any  other  abstract  syntax  may  be  supported. 


4)  Abstract  syntaxes  will  be  identified  by  registered  name. 


11.4  Transfer  Syntaxes 

1)  The  following  transfer  syntaxes  must  be  supported  for  all  mandatory 
abstract  syntaxes  (also  for  NBS-AS2  and  NBS-AS3  if  implemented). 

- NBS-TS1 
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2)  Any  other  transfer  syntax  may  be  implemented. 

3)  Transfer  syntaxes  will  be  identified  by  registered  name. 


12.  COMMON  APPLICATION  SERVICE  ELEMENTS  PROTOCOL 


Presently,  the  following  agreements  apply  only  when  using  FTAM. 

CASE  Part  2 Association  Control  Services  are  defined  to  meet  the  needs  of 
many  applications.  The  CASE  Part  2 Association  Control  Service  is  defined 
in  ISO  DIS  8649/2  and  the  CASE  Part  2 Association  Control  Protocol  is 
defined  in  ISO  DIS  8650/2.  The  general  agreements  about  the  implementation 
of  CASE  are  documented  below. 


12.1  General 

1)  Implementations  will  be  based  on  the  DIS  version  of  ISO  8649/2  and 
ISO  8650/2. 

2)  A conformant  implementation  must  be  ISO  conformant  as  well  as  meet 
all  of  the  requirements  of  this  specification. 

3)  All  services  specified  in  ISO  DIS  8649/2  must  be  implemented. 

12.2  Application  Contexts 

1)  The  following  application  contexts  must  be  implemented. 

- ISO  FTAM 


12.3  Application  Entity  Titles 

1)  Application  Entity  Title  will  name  a specific  application  entity  on  a 
specific  node  (AE  Instance). 

2)  An  AE  Instance  corresponds  to  exactly  one  application  process. 

3)  The  naming  of  application  entities  is  external  to  this  specif icaion. 

4)  Application  entity  titles  may  have  a many-to-one  mapping  to  a PSAP 
address  (i.e.,  aliases  may  be  used). 

5)  An  application  entity  title  is  a registered  name  of  type  OBJECT  IDENTIFIER. 

6)  The  application  entity  invocation  does  not  have  an  address. 
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13.  X .400  BASED  MESSAGE  HANDLING  SYSTEM 


13.1  INTRODUCTION 

This  is  an  implementation  agreement  developed  by  the  Implementor's  Workshop 
sponsored  by  the  U.S.  National  Bureau  of  Standards  to  promote  the  useful 
exchange  of  data  between  devices  manufactured  by  different  vendors.  This 
agreement  is  based  on,  and  employs  protocols  developed  in  accord  with, 
the  OSI  Reference  Model.  While  this  agreement  introduces  no  new  protocols, 
it  eliminates  ambiguities  in  interpretations. 

This  is  an  implementation  agreement  for  a Message  Handling  System  (MHS) 
based  on  the  X. 400-series  of  Recommendations  (1984)  from  the  CCITT. 

Figure  13.1.1  displays  the  layered  structure  of  this  agreement. 

This  agreement  can  be  used  over  any  transport  profile.  In  particular, 
this  profile  can  be  used  over  the  transport  protocol  class  0 used  over 
CCITT  X.25,  described  in  Section  7.2  of  this  document.  In  addition,  this 
profile  can  be  used  over  the  transport  profiles  used  in  support  of  MAP 
(Manufacturing  Automation  Protocols)  or  TOP  (Technical  and  Office 
Protocols).  Note  that  the  MAP  or  TOP  environment  must  support  the  reduced 
Basic  Activity  Subset  (BAS)  as  defined  in  X.410. 

The  UAs  and  MTAs  require  access  to  di rectory  and  routi ng  services.  A 
Directory  Service  is  to  be  provided  for  each  (vendor-specific)  domain. 

Except  insofar  as  they  must  be  capable  of  providing  addressing  and  routing 
described  hereunder,  these  services  and  associated  protocols  are  not 
described  by  this  agreement. 

The  material  on  PRMD-PRMD  message  transfer  in  this  implementation  specification 
is  intended  to  be  stable  enough  to  provide  a reliable  guide  to  implementation 
of  X.400.  The  material  on  ADMD-PRMD  and  ADMD-ADMD  is  incomplete  and 
serves  as  an  indication  of  direction. 
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User  Agent  Layer 

CCITT 

X.420 

Message  Transfer  Agent  Layer 

CCITT 

X.411 

Reliable  Transfer  Service  Layer 

CCITT 

X.410 

Presentation  Layer 

CCITT 

X.410  sec.  4.2 

Session  Layer 

CCITT 

X.225 

Figure  13.1.1  The  layered  structure  of  this  implementation  agreement 


13.2  SCOPE 


This  agreement  applies  to  Private  Management  Domains  (PRMDs)  and 
Administration  Management  Domains  (ADMDs).  Three  boundary  interfaces  are 
speci fied: 

A)  PRMD  to  PRMD; 

B)  PRMD  to  ADMD; 

C)  ADMD  to  ADMD. 

In  case  (A),  the  PRMDs  do  not  make  use  of  MHS  services  provided  by  an 
ADMD.  In  cases  (B)  and  (C),  UAs  associated  with  an  ADMD  can  be  the  source 
or  destination  for  messages.  Furthermore,  in  cases  (B)  and  (C),  an  ADMD 
can  serve  as  a relay  between  MDs.  Figure  13.2.1  illustrates  the  interfaces 
to  which  the  agreement  applies. 

X.400  protocols  other  than  the  Message  Transfer  Protocol  (PI)  and  the  ■ 
Interpersonal  Messaging  Protocol  (P2)  are  beyond  the  scope  of  this 
agreement.  Issues  arising  from  the  use  of  other  protocols  or  relating  to 
PI  components  in  support  of  other  protocols  are  outside  the  scope  of  this 
document.  This  agreement  describes  the  minimum  level  of  services  provided 
by  Management  Domains  (MDs).  Provision  for  the  use  of  the  remaining 
services  defined  in  the  X.400  Series  of  Recommendations  is  outside  the 
scope  of  this  document. 

This  agreement  does  not  cover  message  exchange  between  communicating 
entities  within  a domain  even  if  these  entities  communicate  via  PI  or  P2. 
Bilateral  agreements  between  domains  may  be  implemented  in  addition  to 
the  requirements  stated  in  this  document.  Conformance  to  this  agreement 
requires  the  ability  to  exchange  messages  with  conforming  domains  that 
have  made  no  bilateral  agreements. 
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PRMD  = Private  Management  Domain 
ADMD  = Administration  Management  Domain 


A 

I 


B 


Figure  13.2.1  This  agreement  applies  to  the  interface  between: 
(A)  PRMD  and  PRMD;  (6)  PRMD  and  ADMD;  (C)  ADMD  and  ADMD 
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13.3  PRMD  to  PRMD 


This  section  is  limited  in  scope  to  issues  arising  from  the  di rect 
connection  (interface  A in  Figure  13.2.1)  of  two  PRMDs.  "Direct"  means 
that  no  ADMD  provides  MHS  services  to  facilitate  message  interchange. 
"Direct"  does  not  exclude  those  instances  for  which  ADMDs  provide  lower 
layer  services  (e.g.,  X.25).  Figure  13.3.1  schematically  represents  the 
scope  of  this  section. 

These  issues  relate  to  the  use  of  the  UAL  (User  Agent  Layer)  and  MTL 
(Message  Transfer  Layer)  services,  protocol  elements,  recommended  practices 
and  constraints.  In  particular,  this  section  addresses  the  PI  and  P2 
protocols  and  their  related  services  in  a direct  connection  environment. 
This  section  describes  the  minimum  level  of  services  provided  by  a PRMD. 
Provision  for  the  use  of  the  remaining  services  defined  in  the  X.400 
Series  of  Recommendations  is  beyond  the  scope  of  this  section. 
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Figure  13.3.1 


Interconnection  of  private  domains 


13.3.1  Service  Elements  and  Optional  User  Facilities 


This  section  identifies  those  service  elements  and  optional  user 
facilities  that  must  be  provided  in  support  of  PI  and  P2. 


13.3.1.1  Classification  of  Support  for  Services 

The  classification  of  UA  and  MT-Service  elements  is  used  to  define 
characteristics  of  equipment.  Equipment  can  claim  SUPPORT  or  NON-SUPPORT 
of  a Service;  in  the  case  of  UA-service  elements,  a separate  classification 
is  given  for  Origination  and  Reception. 

The  service  provider  is  defined  as  the  entity  providing  the  service,  in 
this  case,  the  MTL  or  the  UAL.  The  service  user  is  either  the  WS  user 
or  the  UAL.  The  classification  of  provider  and  user  relates  to  the  sub- 
layer for  which  the  service  element  is  defined. 


13.3.1.1.1  Support  (S) 


This  means  that: 

a.  The  service  provider  makes  the  service  element  available  to  the 
service  user. 

b.  The  service  user  gives  adequate  support  to  the  MHS  to  invoke  the 
service  element  or  makes  information  associated  with  the  service 
element  available. 

Support  for  Origination  means  that: 

a.  The  service  provider  makes  the  service  element  available  to  the 
service  user  for  invocation. 


b.  The  service  user  gives  adequate  support  to  the  end  user  of  the  MHS  to 
invoke  the  service  element. 


Support  for  Reception  means  that  the  service  provider  makes  information 
associated  with  the  service  element  available  to  the  service  user. 


Note:  A UA-  or  MT-service  element  can  carry  information  from  originator 

to  recipient  only  if: 


O 


o 


the  service  element  is 
the  service  element  is 
all  intermediate  steps 


available  to  the  originator, 
available  to  the  recipient,  and 
carry  the  information. 
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13.3.1.1.2  Non-Support  (N) 


This  means  that  the  service  provider  is  not  requi red  to  make  the  service 
element  available  to  the  service  user.  However,  the  service  provider 
should  not  regard  the  occurrence  of  the  corresponding  protocol  elements 
as  an  error  and  should  be  able  to  relay  such  elements.  Implementations 
making  a profile  available  should  indicate  deviations  (additions  or 
deletions)  with  respect  to  the  requirement  in  the  profile. 


13.3.1.1.3  Not  Used  (N/U) 


This  means  that  although  the  Recommendations  allow  this  service  element, 
this  profile  does  not  use  it. 


13.3.1.1.4  Not  Applicable  (N/A) 

This  means  that  this  service  element  does  not  apply  in  this  particular 
case  (for  originator  or  recipient). 


13.3.1.2  Summary  of  Supported  Services 

a.  Within  a PRMD,  a User  Agent  must  support  al 1 P2  BASIC  IPM  Services 
(X.400)  and  al 1 P2  ESSENTIAL  IPM  Optional  user  facilities  ( X .401 ) 
subject  to  the  qualifiers  listed  in  APPENDIX  A. 

b.  Within  a PRMD,  a MTA  must  support  al 1 BASIC  MT  Services  (X.400)  and 
all  ESSENTIAL  MT  optional  user  facilities  (X.401)  subject  to  the 
qualifiers  listed  in  APPENDIX  A. 

c.  No  support  is  required  of  the  additional  optional  user  facilities  of 
X.401. 


13.3.1.3  MT  Service  Elements  and  Optional  User  Facilities 

Tables  13.3.1  through  13.3.3  show  the  message  transfer  (MT)  service 
elements  and  optional  user  facilities. 


62 


Table  13.3.1  Basic  MT  service  elements 


Service  Elements 

Support  (S) 
Non-support 

or 

(N) 

Access  Management 

N/U  (a) 

Content  Type  Indication 

s 

Converted  Indication 

s 

Delivery  Time  Stamp  Indication 

s 

Message  Identification 

s 

Non-delivery  Notification 

s 

Original  Encoded  Information  Types  Indication 

s 

Registered  Encoded  Information  Types 

N/U  (a) 

Submission  Time  Stamp  Indication 

s 

a:  Not  applicable  to  co-resident  UA  and  MTA. 


Table  13.3.2  MT  optional  user  facilities 
provided  to  the  UA-selectable  on  a per-message  basis 


Support  (S)  or 

MT  Optional  User  Facilities  Categorization  Non-support  (N) 


Alternate  Recipient  Allowed 

E 

S 

Conversion  Prohibition 

E 

S 

Deferred  Del  ivery 

E 

N (b) 

Deferred  Delivery  Cancellation 

E 

N (b) 

Delivery  Notification 

E 

s 

Disclosure  of  Other  Recipients 

E 

N (c) 

Expl  icit  Convers  ion 

A 

N 

Grade  of  Delivery  Selection 

E 

S 

Multi-destination  Delivery 

E 

S 

Prevention  of  Non-delivery  Notification 

A 

N 

Probe 

E 

N (d) 

Return  of  Contents 

A 

N 
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Table  13.3.3  MT  optional  user  facilities 
provided  to  the  UA  agreed  for  a contractual  period  of  time 


MT  Optional  User  Facilities 

Categor  izat  ion 

Support  (S)  or 
Non-Support  (N) 

Alternate  Recipient  Assignment 

A 

N 

Hoi d for  Del  ivery 

A 

N/U 

Implicit  Conversion 

A 

N 

E:  Essential  optional  user  facility. 

A:  Additional  optional  user  facility. 

b:  A local  facility  subject  to  qualifiers  in  APPENDIX  A. 

c:  Support  not  required  for  an  originating  MT  user;  support  must  be 

provided  for  recipient  MT  users. 

d:  Subject  to  qualifiers  in  APPENDIX  A. 

13.3.1.4  IPM  Service  Elements  and  Optional  User  Facilities 

Tables  13.3.4  through  13.3.6  show  the  IPM  service  elements 

and  optional 

user  facil it ies. 

Table  13.3.4  Basic  IPM 

service  elements 

Origination 

Reception 

Service  Elements 

by  UAs 

by  UAs 

Access  Management 

N/U  (a) 

N/U  (a) 

Content  Type  Indication 

s 

s 

Converted  Indication 

N/A 

s 

Delivery  Time  Stamp  Indication 

N/A 

s 

Message  Identification 

S 

s 

Non-delivery  Notification 

S 

N/A 

Original  Encoded  Information 

S 

S 

Types  Indication 

Registered  Encoded  Information  Types 

N/A 

N/A  (a) 

Submission  Time  Stamp  Indication 

S 

s 

IP-message  Identification 

S 

s 

Typed  Body 

s 

s 

(a)  Does  not  apply  to  co-resident  UA  and  MTA. 
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Table  13.3.5  IPM  optional  facilities  agreed  for  a 
contractual  period  of  time 


Service  Elements 

Categorizat ion 

Support  (S) 
Non-Support 

or 

(N) 

Alternate  Recipient  Assignment 

A 

N 

Hold  for  Del  ivery 

A 

N 

Implicit  Conversion 

A 

N 
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Table  13.3.6  I PM  optional  user  facilities 
selectable  on  a per-message  basis 


Origin  at  ion 

Recept  ion 

I PM  Optional  User  Facilities 

by  UAs 

by  UAs 

Alternate  Recipient  Allowed 

A (N) 

A (N) 

Authorizing  Users  Indication 

A (N) 

E (S) 

Auto-forwarded  Indication 

A (N) 

E (S) 

Blind  Copy  Recipient  Indication 

A (N) 

E (S) 

Body  Part  Encryption  Indication 

A (N) 

E (S) 

Conversion  Prohibition 

E ($) 

E (S) 

Cross-referencing  Indication 

A (N) 

E (S) 

Deferred  Del ivery 

E (N)  (f) 

N/A 

Deferred  Delivery  Cancellation 

A (N/U)  (f) 

N/A 

Delivery  Notification 

E (S) 

N/A 

Disclosure  of  Other  Recipients 

A (N) 

E (S) 

Expiry  Date  Indication 

A (N) 

E (S) 

Explicit  Conversion 

A (N) 

N/A 

Forwarded  IP-message  Indication 

A (N) 

E (S) 

Grade  of  Delivery  Selection 

E (S) 

E (S 

Importance  Indication 

A (N) 

E (S) 

Multi-destination  Delivery 

E (S) 

N/A 

Multi-part  Body 

A (N) 

E (S) 

Non-receipt  Notification 

A (N) 

A (NJ 

Obsoleting  Indication 

A (N) 

E (S) 

Originator  Indication 

E (S) 

E (S) 

Prevention  of  Non-delivery  Notification 

A (N) 

N/A 

Primary  and  Copy  Recipients  Indication 

E (S) 

E (S) 

Probe 

A (N) 

N/A 

Receipt  Notification 

A (N) 

A (N) 

Reply  Request  Indication 

A (N) 

E (S) 

Replying  IP-message  Indication 

E (S) 

E (S) 

Return  of  Contents 

A (N) 

N/A 

Sensitivity  Indication 

A (N) 

E (S) 

Subject  Indication 

E (S) 

E (S) 

f:  A local  facility  subject  to  qualifiers  in  APPENDIX  A. 
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13.3.2  X.400  Protocol  Definitions 


13.3.2.1  Introduction 


This  section  reflects  the  agreements  of  the  NBS/OSI  Workshop  regarding 
PI  and  P2  protocol  elements. 

13.3.2.1.1  Protocol  Classification 


The  protocol  classifications  are  defined: 

a)  UNSUPPORTED  = X 

These  elements  may  be  generated,  but  no  specific  processing  should  be 
expected  in  a relaying  or  delivering  domain.  A relaying  domain  must  at 
least  relay  the  semantics  of  the  element.  The  absence  of  these  elements 
should  not  be  assumed,  in  a relaying  or  delivering  domain,  to  convey  any 
significance. 

b)  SUPPORTED  = H 

These  elements  may  be  generated.  However,  implementations  are  not  required 
to  be  able  to  generate  these  elements.  Appropriate  actions  shall  be 
taken  in  a relaying  or  delivering  domain. 

c)  GENERATABLE  = G 

Implementations  must  be  able  to  generate  and  handle  these  protocol 
elements,  although  they  are  not  necessarily  present  in  all  messages 
generated  by  implementations  of  this  profile.  Appropriate  actions  shall 
be  taken  in  a relaying  or  delivering  domain. 

d)  REQUIRED  = R 

Implementations  of  this  profile  must  always  generate  this  protocol  element. 
However,  its  absence  cannot  be  regarded  as  a protocol  violation  as  other 
MHS  implementations  may  not  require  this  protocol  element.  Appropriate 
actions  shall  be  taken  in  a relaying  or  delivering  domain. 

e)  MANDATORY  = M 

This  must  occur  in  each  message  as  per  X.411  or  X.420  as  appropriate; 
absence  is  a protocol  violation.  Appropriate  actions  shall  be  taken  in  a 
relaying  or  delivering  domain. 
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13.3.2.1.2  General  Statements  on  Pragmatic  Constraints 


a.  Where  a protocol  element  is  defined  as  a choice  of  Numeric  String  and 
Printable  String  (i.e.,  Country  Name,  Administration  Domain  Name  and 
Private  Domain  Identifier),  then  a numeric  value  encoded  as  a printable 
string  is  equivalent  to  the  same  value  encoded  as  a numeric  string. 

b.  The  maximum  number  of  recipients  in  a single  MPDU  is  32K  - 1 (that 

is,  32767).  However,  no  individual  limits  on  the  number  of  occurrences 
(recipients)  are  placed  on  the  following  protocol  elements:  Authorizing 

Users,  Primary  Recipients,  Copy  Recipients,  Blind  Copy  Recipients, 
Obsoletes  and  Cross  References.  Additionally,  there  is  no  limit  on 
the  number  of  Reply  to  Users.  This  is  a local  matter  for  the 
originating  system. 

c.  Use  of  strings.  A Printable  String  is  defined  in  terms  of  the  number 
of  characters,  which  is  the  same  number  of  octets.  For  T.61  strings 
the  number  of  octets  is  twice  the  number  of  characters  specified. 

d.  The  ability  to  generate  maximum  size  elements  is  not  required,  with 
the  exception  of  the  component  fields  in  the  Standard  Attribute  List, 
in  which  case  it  is  required. 


13.3.2.1.3  MPDU  Size 

The  following  agreements  govern  the  size  of  MPDUs: 

a.  All  MTAEs  must  support  at  least  one  MPDU  of  at  least  one  megabyte. 

b.  The  size  of  the  largest  MPDU  supported  by  a UAE  is  a local  matter. 
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13.3.2.2  PI  Protocol  Elements 


13.3.2.2.1  PI  Envelope  Protocol  Elements 

Table  13.3.7  contains  Protocol  Elements  and  their  classes. 

Table  13.3.7  PI  protocol  elements 


El  ement 

Cl  ass 

Restrictions  and  Comments 

MPDU 

UserMPDU 

G 

Del iveryReportMPDU 

G 

ProbeMPDU 

H 

UserMDPU 

UMPDUEnvelope 

M 

UMPDUContent 

M 

UMPDUEnvel ope 

MPDUIdent if  ier 

M 

originator 

M 

or ig inal Encoded In format  ion Types 

G 

If  this  field  is  absent,  then 
the  Encoded  Information  Type 
is  "unspecified". 

ContentType 

M 

UAContentID 

H 

Maximum  length  = 16  characters. 

Priority 

G 

PerMessageFlag 

G 

Maximum  length  = 2 octets. 

deferredDel ivery 

X 

PerDomainBilateral  Info 

X 

No  limit  on  number  of  occurrences 

Recipientlnfo 

M 

Maximum  number  = 32K  - 1 occurr- 
ences. More  severe  limitations  are 

Tracelnformat ion 

M 

by  bilateral  agreement. 

UMPDUContent 

M 

MPDUIdent if ier 

G1  obal Domain Ident if ier 

M 

IA5Str  ing 

M 

Maximum  length  = 32  characters, 
graphical  subset  only.  Refer  to 
T.50  for  clarification  of  graphica 

PerMessageFlag 

subset. 

discloseRecipients 

H 

con  vers  ionProh  ibited 

G 

al  ternateRec ip ientAl lowed 

H 

contentReturnRequest 

X 

PerDomainBilateral  Info 

CountryName 

M 

Maximum  length  = 3 characters. 

Admin istrat ionDoma inName 

M 

Maximum  length  = 16  characters. 

B il  ateral  Info 

M 

Maximum  depth  = 8;  maximum 
length  = 1024 

octets  (including  encoding). 

(continued  on  next  page) 
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Table  13.3.7  PI  protocol  elements.  Continued 


Element 


Class  Restrictions  and  Comments 


Rec  ip  ient Info 

rec ip ient 

M 

Extens  ionldent if ier 

M 

Maximum  value  = 32K  - 1 (32767). 

perRecip ientFl ag 

M 

Maximum  length  = 2 octets. 

Expl  ic itConvers  ion 

X 

perRecipientFlag 

Respons ib il  ityFl ag 

M 

ReportRequest 

M 

UserReportRequest 

M 

T racelnformat ion 

Reference  should  be  made  to 
Version  3 of  the  X.400  Imple- 
mentor's Guide  for  information 

G1 obal Domain Ident if ier 

M 

related  to  Trace  sequencing. 

DomainSuppl  iedlnfo 

M 

Doma inSuppl iedlnfo 

arrival 

M 

deferred 

X 

act  ion 

M 

converted 

H 

prev ious 

X 

ORName 

Encodedlnformat ionTypes 

bit  string 

M 

Delivery  can  only  occur  if  match 
is  made  with  Registered  Encoded 
Information  Types.  Individual 
vendors  may  impose  limits. 
Maximum  length  = 3 octets. 

G3NonBas icParameters 

X 

Tel etexNonBas icParameters 

X 

Presentat ionCapabil ities 

X 

Del  iveryReportMPDU 

Del iveryReportEnvelope 

M 

Del  iveryReportContent 

M 

Del iveryReportEnvelope 

report 

M 

orig  inator 

M 

Trace  In  format  ion 

M 

Del iveryReportContent 

original 

M 

intermed  iate 

X 

UAContentID 

G 

Report edRec ip ient Info 

M 

Maximum  number  = 32K  - 1 occurrences 

returned 

H 

Can  only  be  issued  if  specifically 
requested  in  the  originating  message 
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(Continued  on  next  page) 


Table  13.3.7  PI  protocol  elements,  continued 


Element 

Class 

Restriction  and  Comments 

bill  inglnformat ion 

X 

Maximum  depth  = 8;  maximum 
length  = 1024  octets  (including 
encod  ing) . 

ReportedRecipientlnfo 

recipient 

M 

Extens ionsldent if ier 

M 

PerRecipientFlag 

M 

LastTrace In  format  ion 

M 

intendedRecipient 

H 

Suppl  ementary  Informat  ion 

X 

Maximum  length  = 64  characters. 
NOTE:  This  is  subject  to 

change.  Value  is  pending 
verification  by  the  CCITT  SG 
VIII  or  IX. 

LastTracelnformat  ion 

arrival 

M 

converted 

H 

Report 

M 

Report 

Del  iveredlnfo 

G 

Generated  if  del  ivery  is  reported 

NonDel iveredlnfo 

G 

Generated  if  failure  to  deliver 
is  reported. 

Del iveredlnfo 

del  ivery 

M 

typeofUA 

R 

This  element  must  be  generated  by 
PRMDs  with  a PRIVATE  value. 

NonDel iveredlnfo 

ReasonCode 

M 

D iagnost icCode 

H 

Whenever  possible,  use  a meaningful 
diagnostic  code. 

ProbeEnvel ope 

probe 

M 

originator 

M 

ContentType 

M 

UAContent  ID 

H 

Maximum  length  = 16  characters. 

original 

G 

If  this  field  is  absent,  then  the 
Encoded  Information  Type  is 
"unspecified". 

(Continued  on  next  page) 
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Table  13.3.7  PI  protocol  elements,  continued 


Tracelnformat ion  (under  Probe 

Envelope) 

M 

PerMessageFl ag 

G 

contentLength 
PerDomainBilateral  Info 
Rec ip  ientlnfo 

H 

X 

M Maximum  number  = 32K  - 1 

occurren ces. 

— End  of  Definitions 
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13.3.2.2.2  ORName  Protocol  Elements 


Only  form  1 variant  1 0/R  names  are  supported. 

Table  13.3.8  contains  ORName  Protocol  Elements. 

Table  13.3.8  ORName  protocol  elements 

Element  Class  Restrictions  and  Comments 


ORName 

StandardAttributeList  M 

DomainDef inedAttributeList  X 

StandardAttributeList  (1) 

CountryName  R 

Admin ist rat ionDomainName  (4)  R 

X.121Address  X 

Terminal  ID  X 

PrivateDomainName  (2)  G 

Organ izationName  (2)  G 

Un  iqueUAIdent if ier  X 

Personal  Name  G 


Organ izat ional Un it  (3)  G 

DomainDef inedAttributeList  (5)  X 

type  M 

value  M 

Personal  Name 

surName  M 

given Name  G 

initials  G 

generat ionQual if ier  G 


As  defined  in  X.411,  Maximum 
length  = 3 characters. 

Maximum  length  = 16  characters 
or  digits. 

Maximum  length  = 15  digits. 

Maximum  length  = 24  characters. 
Maximum  length  = 16  characters. 
Maximum  length  = 64  characters. 
Maximum  length  = 32  digits. 

Maximum  length  of  values  of  sub- 
elements = 64  characters. 

NOTE:  The  possibility  that  this 

value  may  be  reduced  to  40 
characters  is  for  further 
study  by  the  CCITT. 

Maximum  length  = 32  characters  per 
occurrence.  A maximum  of  four 
occurrences  are  allowed. 

Maximum  = 4 occurrences. 

Maximum  length  = 8 characters. 
Maximum  length  = 128  characters. 


Maximum  length  = 40  characters. 
Maximum  length  = 16  characters. 
Maximum  length  = 5 characters; 

excluding  surname  initial  and 
punctuation  and  spaces. 

Maximum  length  = 3 characters. 
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Global  Domain  Identifier 

Count ryName  M Maximum  length  = 3 characters. 

Admi ni strati onDomai nName  (4)  M Maximum  length  = 16  characters  or 


Pri vateDomai nldentifier 

digits. 

R Maximum  length  = 16  characters  or 

digits.  This  element  must  be 
generated  by  PRMDs. 

— End  of  Definitions— 

(Continued  on  next  page) 
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Table  13.3.8  ORName  Protocol  Elements,  Continued 


Notes: 

(1)  The  following  apply  for  comparison  of  the  Standard  Attributes  of  an 
0/R  Name: 

1)  Lower  case  is  interpreted  as  upper  case  (for  IA5). 

2)  Multiple  spaces  may  be  interpreted  as  a single  space.  Originating 
domains  shall  only  transmit  single  significant  spaces.  If  multiple 
spaces  are  transmitted,  non-delivery  may  occur. 

(2)  At  least  one  of  these  must  be  supplied. 

(3)  These  should  be  sent  in  ascending  sequence,  from  the  least  significant 
<Organizat ional  Un  it>  (lowest  in  organization  hierarchy)  to  the  most 
significant.  Only  those  specified  should  be  sent.  (That  is,  an  un- 
specified <0rgan izat ional  Un  it>  should  not  be  sent  along  as  a field  of 
[null]  content,  nor  zero  length,  etc.) 

(4)  This  attribute  shall  contain  one  space  in  all  ORNames  of  messages 
originated  in  a PRMD  that  is  not  connected  to  an  ADMD,  and  in  ORNames 
of  recipients  reachable  only  through  a PRMD;  otherwise,  this  attribute 
shall  contain  an  appropriate  ADMD  name. 

(5)  Many  existing  mail  systems  require  attributes  not  present  in  these 
agreements.  Domain  Defined  Attributes  are  a method  of  providing 
these.  Failure  to  support  the  specification  of  DDAs  may  prevent 
successful  interworking  with  such  existing  mail  systems  until  such 
time  as  all  mail  systems  are  capable  of  supporting  delivery  via  the 
standard  attribute  list  only.  Specific  recommendations  on  the  use 
of  DDAs  are  in  the  Recommended  Practices  section. 


13.3.2.3  P2  Protocol  Profile  (Based  on  [X.420]) 


Tables  13.3.9  and  13.3.10  classify  the  support  for  the  P2  protocol  elements 
required  by  this  profile.  The  tables  give  restrictions  and  comment  in 
addition  to  [X.420]. 

Restriction  on  length  is  one  of  the  types  of  restrictions.  The  reaction 
of  implementation  to  a violation  of  this  restriction  is  not  defined  by 
this  profile. 
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13.3.2.3.1  P2  Protocol  - Heading 

Table  13.3.9  below  specifies  the  support  for  protocol  elements  in  P2  Headings. 


Table  13.3.9  P2  heading  protocol  elements 


El  ement 

Class 

Restrictions  and  Comments 

UAPDU 

IM-UAPDU 

G 

SR-UAPDU 

X 

IM-UAPDU 

Head  ing 

M 

Body 

M 

Head  ing 

IPMessageld 

M 

or  iginator 

R 

author  izingUsers 

H 

primaryRecipients 

G 

At  least  one  of  primaryRecipients, 

copyRecipients 

G 

copyRecipients,  or  bl indCopyRecip ients 

bl  indCopyRecipients 

H 

must  be  present. 

inReplyTo 

G 

obsoletes 

H 

crossRefe rences 

H 

subject 

G 

Maximum  length  = 256  octets;  the 

expiryDate 

H 

ability  to  generate  the  maximum  size 
subject  is  not  required. 

replyBy 

H 

replyToUsers 

H 

importance 

H 

Appropriate  action  is  for  further  study 

sens  it  ivity 

H 

Appropriate  action  is  for  further  study 

autoforwarded 

H 

IPmessageld 

ORName 

H 

PrintableString 

M 

Maximum  length  = 64  characters. 

ORDescriptor 

ORName 

H 

Specify  the  ORName  whenever  it  is 

freeformName 

H 

possible.  See  APPENDIX  B. 
Maximum  length  = 64  characters, 

telephoneNumber 

X 

graphical  subset  only  (128  octets). 
Maximum  length  = 32  characters.  This 

Recipient 

M 

allows  for  punctuation.  It  does  not 
take  into  account  possible  future 
use  by  ISDN. 

ORDescriptor 

M 

reportRequest 

X 

replyRequest 

H 

(Continued  on  next  page) 
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Table  13.3.9  P2  heading  protocol  elements,  continued 


Element 


Class  Restrictions  and  Comments 


Body 

BodyPart  G 


SR-UAPDU 

nonReceipt  H 

receipt  H 

reported  M 

actualRecipient  R 

intendedRecipient  H 

converted  X 

Non Receipt  In  format  ion 

reason  M 

nonReceiptQual if ier  H 

comments  H 

returned  H 

Receipt  Informat  ion 

receipt  M 

typeOfReceipt  H 

Supplementary Informat  ion  X 


l 

I 


No  limit  on  number  of  BodyParts. 

No  limit  on  length  of  any  BodyPart 
or  the  depth  of  ForwardedIPMessage 
BodyParts  nested.  Classification  is 
subject  to  pending  CCITT  resolution. 


Maximum  length  = 256  characters. 
May  only  be  issued  if  specifically 
requested  by  originator. 


Maximum  length  = 64  characters. 
NOTE:  This  value  is  pending 

verification  by  the  CCITT  SG 
VIII  or  IX. 


13.3.2.3.2  P2  Protocol  - BodyParts 

All  BodyParts  with  identifiers  in  the  range  0 up  to  and  including  16K  -1 
are  legal  and  should  be  relayed.  BodyPart  identifiers  corresponding  to 
X.121  Country  Codes  should  be  interpreted  as  described  in  section 
13.4.3.2.1. 
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13.3.2.3.2.1  Privately  Defined  BodyParts 

This  section  describes  an  interim  means  for  identifying  privately  defined 
BodyParts.  This  subsection  shall  be  replaced  in  a future  edition  taking 
into  account  CCITT  recommendations  with  equivalent  functionality.  • 

BodyPart  ::=  CHOICE 
[OD IMPLICIT  IA5Text, 

[1]IMPLICIT  TLX, 


[234] IMPLIC IT  UKBodyParts, 


[310]IMPLICIT  USABodyParts , 


] 

Where  UKBodyParts  and  USABodyParts  are  defined  as: 

SEQUENCE  BodyPartNumber,  ANY 
BodyPartNumber  ::=  INTEGER 

In  the  Encodedlnformat ionTypes  of  the  PI  Envelope,  the  undefined  bit  must 
be  set  when  a message  contains  a privately  defined  BodyPart.  Each  UA  that 
expects  such  BodyParts  should  include  undefined  in  the  set  of  deliverable 
Encodedlnformat  ionTypes  it  registers  with  the  MTA. 

All  BodyPartNumbers  assigned  must  be  interpreted  relative  to  the  BodyPart 
in  which  it  is  used,  which  is  that  tagged  with  the  value  [310]  in  the  case 
of  those  defined  within  the  United  States.  The  NBS  assigns  unique  message 
BodyPartNumbers  for  privately  defined  formats  within  the  United  States. 

Implementations  are  required  to  generate  and  image  IA5Text. 

Implementations  should  specify  the  other  BodyPart  types  supported. 

If  an  implementation  supports  a particular  BodyPart  type  for  reception, 
it  should  also  be  able  to  support  that  BodyPart  type  for  reception  if 
this  is  part  of  a ForwardedIPMessage. 

For  the  BodyPart  types  currently  considered,  support  for  the  protocol 
elements  is  as  indicated  in  Table  13.3.10. 
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13.3.2.3.2.2  P2  BodyPart  Protocol  Elements 


Table  13.3.10  P2  BodyParts 


El ements 


Class  Restrictions  and  Comment 


BodyPart 

IA5Text  G 

TLX  X 

Voice  X 

G3Fax  X 

TIF0  X 

TTX  X 

Videotex  X 

NationallyDefined  X 

Encrypted  X 

ForwardedIPMessage  H 

SFD  X 

TIF1  X 

IA5Text 

repertoire  H 

IA5String  M 


TLX 


Voice 

Set 

Bitstring  M 

G3Fax 

numberOfPages  X 

G3NonBasicParameters  X 

SEQUENCE  (OF  BIT  STRING)  M 

BIT  STRING  H 


G3NonBasi  cParaineters 


TIFO 

T.73Document  M 

T.73ProtocolEl ement  H 

TTX 

numberOfPages  X 

tel exCompatibl e X 

TeletexNonBasicParams  X 

SEQUENCE  (of  T61String)  M 

T61String  H 

Tel etexNonBasi cParams 

graphicCharacterSets  X 

control CharacterSets  X 

pageFormats  X 

mi scTermi nal Capabi 1 i ti es  X 

privateUse  X 


For  rendition  of  IA5Text  see 
APPENDIX  C. 

For  further  study  by  CCITT. 

For  further  study  by  CCITT. 

See  NOTE: 

Support  for  individual  elements 
for  further  study. 

See  NOTE: 


See  NOTE; 
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(Continued  on  next  page) 


Table  13.3.10  P2  BodyParts,  Continued 


Element 

Class 

Restrictions  and  Comments 

V ideotex 

SET 

For  further  study  by  CCITT 

V ideotexString 

M 

Nat  ional  lyDef  ined 

ANY 

M 

Encrypted 

SET 

For  further  study  by  CCITT 

BIT  STRING 

M 

Forwarded  I PMes sage 

del  ivery 

H 

Del  iverylnformat  ion 

H 

IM-UAPDU 

M 

Del  iverylnformat  ion 

ContentType 

M 

originator 

M 

original 

M 

Priority 

G 

Del iveryFlags 

M 

otherRecipients 

H 

thisRecipient 

M 

intendedRecipient 

H 

convert  ed 

X 

submiss  ion 

M 

SFD 

SFD. Document 

M 

TIF1 

T.73  Document 

M 

Note:  This  element  is  not  an  addition  to  the  definition  of  the  BodyPart. 

It  is  described  here  to  show  that  the  SEQUENCE  may  contain  zero 
elements.  A Problem  Report  has  been  submitted  to  the  CCITT  to 
clarify  whether  this  is  permissible.  The  NBS/OSI  Workshop  will 
adopt  the  CCITT  decision. 
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13.3.3  Reliable  Transfer  Server  (RTS) 


13.3.3.1  Implementation  Strategy 

Based  on  X.410  clause  3 and  X.411  clause  3.5. 

13.3.3.2  RTS  option  selection 

a)  The  maximum  number  of  simultaneous  associations  is  not  limited  in  this 
profile;  if  the  capacity  of  a system  is  exceeded,  it  should  not  initiate 
or  accept  additional  associations. 

b)  Associations  are  established  by  the  MTA  which  has  messages  to  transfer. 

c)  Associations  are  released  when  they  are  not  needed.  Associations  may 
also  be  ended  prematurely  due  to  internal  problems  of  the  RTS. 

d)  For  both  monologue  and  two  way  alternate  associations,  the  initiator 
keeps  the  initial  turn. 

When  establishing  an  RTS  association,  the  following  rules  apply  to  the 

use  of  parameters  in  addition  to  those  in  X.410  clause  3.2.1: 


Dialogue  mode: 


Initial  turn: 


Monologue  must  be  supported  for  this 
profile;  two-way  alternate  is  used  only 
if  both  partners  agree. 

Kept  by  the  initiator  of  the  association. 


The  ' priority-mechani sm'  and  the  'transfer-time  limit'  are  regarded  as 
local  matters. 
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13.3.3.3  RTS  Protocol  Options  and  Clarifications 


Realization  of  the  RTS  protocol  is  subject  to  the  following  rules  in 
addition  to  those  specified  in  X.410  clause  4: 

a.  One  RTS  association  corresponds  with  one  or  more  consecutive  session 
connections  (not  concurrent  ones).  The  first  is  opened  with 
ConnectionData  of  type  OPEN,  and  subsequent  ones  are  opened  with  type 
RECOVER. 

b.  Recovery  of  Session  connection  is  only  by  RTS  initiator. 

c.  Checkpoint  size: 

• Checkpointing  and  No  Checkpointing  should  be  supported.  Whenever 
possible,  checkpointing  should  be  used. 

• The  minimum  checkpoi ntSize  is  1 (that  is,  1024  octets). 

d.  Window  size: 

• Minimal  value  of  1 (if  checkpointing  is  supported). 

• WindowSize  = 1 means:  After  an  S-SYNCH-MINOR  request  is  sent,  wait 

until  the  confirmation  is  received  before  issuing  an  S-DATA,  S-SYNCH- 
MINOR,  or  S-ACTIVITY-END  request. 

e.  APDUs  should  not  be  blocked  into  one  activity. 

f.  Only  one  SSDU  shall  be  transferred: 

• Between  two  adjacent  minor  synch  points. 

• Between  minor  synch  points  and  adjacent  S-ACTIVITY-START  and  S-ACTIVITY- 
END  requests. 

• Between  S-ACTIVITY-START  and  S-ACTIVITY-END  without  checkpoints. 

g.  A monologue  association  is  defined  as  follows: 

f The  RTS  user  responsible  for  establishing  the  association  is  called 
the  initiator. 

• The  initiator  keeps  the  initial  turn. 

• APDUs  are  transferred  in  the  direction  of  the  initiator  to  the  recipient 
only. 

• There  shall  be  no  token  passing. 

• Only  the  initiator  can  effect  an  orderly  release  of  the  association. 

h.  A two-way  alternate  session  is  as  described  in  X.410. 
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i.  In  the  UserData  parameter  of  the  S-U-ABORT,  the  Refl ectedParameter  will 
not  be  used  in  the  Abort  In  format  ion  element. 

j.  When  the  S-ACTIVITY-RESUME  is  used  to  resume  an  activity  in  the  same 
session  connection  as  the  one  in  which  it  started,  this  must  happen 
immediately  after  the  activity  has  been  interrupted  (i.e.,  no  intervening 
activity  can  occur).  Otherwise,  [X.410  clause  4.3  paragraph  1]  may  be 
violated. 

k.  When  S-ACTIVITY-RESUME  is  used  to  resume  an  activity  started  in  another 
session  connection,  the  following  conditions  must  be  met: 

0 The  current  session  connection  is  of  type  "recover". 

° The  value  of  01 dSess ionConnect  ion  Identifier  in  S-ACTIVITY-RESUME  must 
match  the  value  of  the  Sess ionConnect ionldent if ier  parameter  used  in 
the  S-CONNECT  of  the  prior  session  connection.  This  value  is  also 
identical  to  the  Sess  ionConnect  ionldentif  ier  in  the  Connect  ionData  (in 
PConnect,  in  SS-UserData)  for  the  current  session  connection. 

° This  must  occur  as  the  first  activity  of  the  next  session  connection 
for  the  same  RTS-associat ion.  It  must  be  the  first,  otherwise  [X.410 
clause  4.5.1  point  1]  is  violated. 

Note:  It  is  in  the  same  RTS-ASSOCIATION  because  the  use  of  S-ACTIVITY- 

RESUME  only  makes  sense  within  the  scope  of  one  RTS  association. 

l.  If  the  transfer  of  an  APDU  is  interrupted  before  the  confirmation  of  the 
first  checkpoint,  the  value  of  the  Synchron izat ionPointSerial Number  in 
S-ACTIVITY-RESUME  should  be  zero. 

The  S-ACTIVITY-RESUME  must  be  immediately  followed  by  an  S-ACTIVITY- 
DISCARD. 

m.  In  S-TOKEN-PLEASE , the  UserData  parameter  shall  contain  an  integer 
conforming  to  X.409  which  conveys  the  priority. 

n.  The  receiving  RTS  can  use  the  value  of  the  Reason  parameter  in  the 
S-U-EXCEPTION-REPORT  to  suggest  to  the  sending  RTS  that  it  should 
either  interrupt  or  discard  the  current  activity. 

As  stated  in  Version  3 of  the  X.400  Series  Implementor's  Guide, 

"On  receipt  of  an  'unrecoverable  procedure  error'  the  current  activity 
is  not  recoverable  and  the  sending  RTS  issues  an  S-ACTIVITY-DISCARD. 

On  receipt  of  any  other  reason  code  (including  an  undefined  value), 

the  sending  RTS  issues  an  S-ACTIVITY-INTERRUPT  followed  by  an  S-ACTIVITY- 

RESUME." 

o.  In  the  case  of  S-P-ABORT,  the  current  activity  (if  any)  is  regarded 
as  interrupted,  rather  than  discarded. 
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p.  The  following  table  illustrates  the  legal  negotiation  possibilities 

allowed  by  X.410  clause  4.2.1  regarding  checkpoint  size  and  window  size: 


Table  13.3.11  Checkpoint  window  size  of  IP 


acceptor  answer 

CS  = 0 

(or  unspecified) 
WS  unspecified 

CS  = m 
WS  = j 

or  unspecified 

CS  = n 
WS  = j 

(or  unspecified' 

in  it  iator 

CS  = 0 

(or  unspecified) 
WS  = i 

(or  unspecified) 

legal 

legal 

legal 

• 

proposal 

CS  = k 
WS  = i 

(or  unspecified) 

legal 

legal 

not  allowed 

Legend: 

- CS  means  CheckpointSize 

- WS  means  Windows ize 

- i,  j,  k,  m,  and  n are  integer  values  with  the  following  relations: 

0 < m < k < n (values  assigned  to  CS) 

0 < j < i (values  assigned  to  WS) 

- For  unspecified  parameters,  the  default  applies.  In  this  case, 
the  numeric  relations  apply,  that  is,  the  default  values  substitute 
for  the  unspecified  integer. 
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13.3.3.4  RTS  Protocol  Limitations 


The  RTS  Protocol  Limitations  for  this  profile  are  listed  in  Table  13.3.12. 


Table  13.3.12  RTS  protocol  elements 


Element  Class  Restriction 


PConnect 

M 

DataTransferSyntax 

M 

Value  = 0. 

pUserData 

M 

checkpointSize 

H 

windows  ize 

H 

dial ogueMode 

H 

ConnectData 

M 

appl  icat ionProtocol 

R 

Value  = 1. 

Connect  ionData 

open 

G 

recover 

G 

open 

RTS  User  Data 

G 

recover 

Sess  ionConnect ion  ID 

G 

RTS  User  Data 

mTAName 

G 

Maximum  length  32 

password 

G 

characters  graphic 
subset  of  IA5  only. 
Maximum  length  64  octets 

< nul 1 RTS  User  Data  > 

G 

graphic  subset  of 
IA5  only. 

Generated  if  other 

validation  methods 
are  used. 

Sess  ionConnect ion Ident if ier 

Call ingSSUserReference 

M 

Maximum  length  64  octets 

CommonReference 

M 

including  encoding  = 
62  octets  of  T.61. 

Add  it  ional Reference 

G 

Maximum  length  4 octets 

Informat  ion 

including  encoding  = 

PAccept 

G 

2 octets  of  T.61. 

DataT  ransferSyntax 

M 

Value  = 0. 

(Continued  on  next  page) 
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Table  13.3.12  RTS  protocol  elements,  continued 


Element 

Class 

Restriction 

pUserData 

M 

checkpointSize 

H 

windows  ize 

H 

Connect  ionData 

G 

PRefuse 

G 

RefuseReason 

M 

SS  User  Data 

(in  S-TOKEN-PLEASE) 

G 

Abortlnformat ion 
(in  S-U-ABORT) 

•G 

AbortReason 

H 

ref lectedParameter 

X 

Restricted  to  8 bits, 
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13.3.4  Use  of  Session  Services 


The  session  requirements  and  use  of  session  are  covered  in  section  8 of 
this  document. 


13.3.5  Data  Transfer  Syntax 

This  section  defines  Presentation  Transfer  Syntax  and  notation  rules 
applicable  to  these  agreements.  Implementations  must  conform  EXACTLY 
as  specified  in  X.409  with  no  further  restrict  ions.  APPENDIX  C defines 
rendition  of  IA5  Text  and  T61  characters. 
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13.4  PRMD  to  ADMD  and  ADMD  to  ADMD 


13.4.1  Introduction 


This  section  defines  the  implementation  agreements  that  apply  to  the 
interface  between  two  management  domains  when  at  least  one  is  an  ADMD.  A 
message  arriving  at  an  ADMD  has  either  no  recipient  within  that  domain  or 
one  or  more  recipients  within  that  domain.  In  the  former  case,  the  ADMD 
serves  as  a relay  between  two  or  more  domains  and  the  actions  required  of 
that  ADMD  are  independent  of  the  nature  (PRMD  or  ADMD)  of  the  domains. 

In  the  latter  case,  the  ADMD  is  responsible  for  delivering  messages  to  the 
proper  recipient(s)  within  its  jurisdiction,  and  may  also  be  responsible 
for  relaying  the  message. 

Given  the  two  roles  for  an  ADMD,  this  subsection  describes  two  distinct  sets 
of  functional  requirements  for  an  ADMD.  The  first  is  the  relaying 
requirement  that  is  needed  to  provide  PRMD  and  other  ADMD  interworking. 

The  second  is  analogous  to  the  PRMD's  support  to  its  customers  through 
the  integrated  UAs.  These  are  distinct  functional  differences.  The 
services  provided  to  the  UAs  of  an  ADMD  are  independent  of  the  requirement 
that  an  ADMD  provide  a function  for  interworking  with  any  type  of  Management 
Domain  (MD).  Figure  13.4.1  illustrates  the  two  roles  played  by  an  ADMD. 

This  section  is  presented  in  the  form  of  deviations  from  the  agreements 
applicable  to  PRMD-to-PRMD  (section  13.3.0).  Unless  explicitly  noted 
in  the  remainder  of  this  section,  all  of  the  specifications  for  PRMD  to 
PRMD  apply  to  PRMD  to  ADMD  and  ADMD  to  ADMD. 
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(b) 


Figure  13.4.1  An  ADMD  may  (b)  or  may  not  (a)  serve  as  a relay. 
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13.4.2  ADMDs  as  Relays 


The  following  apply  to  an  ADMD  when  it  serves  as  a relaying  domain. 


1)  ADMDs  will  relay  all  content  types  (not  just  P2)  unchanged  in  the 
absence  of  a request  for  conversion. 

2)  PI  Protocol  Change 

Protocol  Elements  Class  Comments 


Del i veryReportContent 

intermediate  Trace  Information  G 


If  requested  by  other 
than  the  originating 
domain,  return  of  the 
desired  information 
cannot  be  assured, 
as  the  return  path 
may  be  different 
and  exclude  that  domain. 


Del i veredlnfo 
typeOfUA 


H This  element  must  be 

generated  by  PRMDs  with 
value  of  “PRIVATE". 


ReportedReci pi ent Info 

Suppl ementary Information  H Domains  providing  access 

to  TELEX/TELETEX  recipients, 
whether  directly  or  indirectly 
as  a result  of  bilateral  agree- 
ments between  domains,  must 
ensure  that  this  information, 
when  present,  is  accessible 
by  the  recipient  of  the 
delivery  report. 

G1 obal Domai n Ident i f i er 

Pri vateDomainldentifier  R For  PRMDs.  ADMDs  shall  take 

appropriate  actions  upon 
receipt  of  this  element. 
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3)  0/R  Names 


0/R  Names  shall  consist  of: 

Count ryName 

Admi ni strati onDomai nName 

as  well  as  one  of  the  following: 

Pri vateDomai nName 

Personal  Name 

OrganizationName 

OrganizationalUnit 

UniqueUAIdentifier 

X121Address 

and  permits  the  optional  inclusion  of  a 
Domai nDefinedAttri buteList 

Note  that  the  destination  Pri vateDomai nName  or  OrganizationName  must 
be  present  if  destined  for  a PRMD.  The  ADMD  relaying  the  message  to  that 
destination  PRMD  requires  this  element. 

PI  Originator  Name 

Management  Domains  (MDs)  must  specify  in  the  ADMD  name  field  of  the  0/R 
Name  StandardAttri buteList  in  PI,  the  name  of  the  administration  domain: 

(a)  to  which  the  message  is  being  sent  (in  recipient  names) 

(b)  from  which  the  message  originated  (in  the  originator  name). 


13.4.3  Interworking  with  Integrated  UAs 

If  the  message  originates  at  a UA  owned  by  an  ADMD,  or  is  delivered  to  such 
a UA,  the  0/R  Name  follows  the  same  Form  1 Variant  1 constraints  as  the  base 
specifications;  except  that  the  ADMD  name  is  the  name  of  the  owning  ADMD  and 
instead  of  supplying  a PRMD  Name,  one  (or  more)  of  the  following  must  be 
provi ded : 


Organi zati onName 
OrganizationalUnit 
Personal  Name 

and  may  optionally  include  a 

Domai nDef i nedAtt ri buteList 
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13.4.4  Differences  with  other  Profiles 


13.4.4.1  NTT  Profile 

There  are  no  outstanding  issues  regarding  interworking  between  NTT- 
conformant  systems  and  NBS-conformant  systems  with  the  exception  of 
the  number  of  recipients.  The  Extension  Identifier  field  may  contain  a 
maximum  value  of  32K-1 ; however,  according  to  the  current  NTT  profile,  if 
a message  with  more  than  256  recipients  is  received,  the  NTT-conformant 
domain  will  generate  a nondelivery  notification.  This  also  applies  to 
the  ReportedReci pientlnfo  in  a delivery  report. 

13.4.4.2  CEPT  Profile 


For  further  study. 

13.4.5  Connection  of  PRMDs  to  Multiple  ADMDs. 

Given  that  Management  Domain  names  (both  PRMD  and  ADMD)  shall  be  unique 
within  the  U.S.,  then  when  an  ADMD  is  presented  a message  for  transfer 
from  a PRMD,  it  will  accept  0/R  Names  (both  originator  and  recipient) 
which  have  an  Admini strati onDomainName  field  value  different  than  the 
administration's  name.  "Accept"  implies  the  attempt  to  route/deliver  the 
message  shall  be  made,  as  appropriate,  based  upon  the  knowledge  that  MD 
names  are  unique. 

Whether  this  functionality  is  required  by  an  administration  for  conformance 
to  this  agreement  is  for  further  study. 

If  a PRMD  is  connected  to  two  or  more  ADMDs  which  are  not  effectively 
connected  (either  directly  or  via  a third  ADMD),  full  X.400  functionality 
shall  not  be  available.  Problems  occur  especially  in  the  areas  of: 

-Nami ng 
-Routi ng 
-Replyi ng. 


13.4.6  Connection  of  an  ADMD  to  a Routing  PRMD 

It  is  possible  for  a collection  of  interconnected  private  domains  to 
establish  one  domain  as  the  "gateway"  to  an  ADMD,  and  hence  to  the  world. 

If  an  ADMD  is  connected  to  such  a gateway  PRMD,  the  individual  private 
domains  shall  be  registered  with  the  administration.  Administrations 
need  not  support  such  connections. 

Note  also  that  upon  receipt  by  the  ADMD  of  a message  originating  somewhere 
within  the  PRMD  collection,  that  the  Tracelnformation  may  contain  more 
than  one  element. 


92 


13.4.7  Management  Domain  Names 


All  Management  Domain  Names  (both  Private  and  Administration)  shall  be 
unique  within  the  U.S. 

A central  naming  authority  shall  be  established  to  register  domain  names. 


13.4.8  Envelope  Validation  Errors 

ADMDs  will  validate  PI  Envelopes  in  the  following  areas: 

a.  The  X.409  syntax  of  all  elements  should  be  checked. 

b.  The  pragmatic  constraint  limits  (lengths  of  fields  and  number  of 
occurrances  of  fields)  should  be  checked. 

c.  Semantic  validation  of  the  following  selected  set  of  elements  should 

be  done:  origi  nator  0/R  Name,  original  Encoded  Inf  ormationTypes  (but 

not  against  the  actual  contents),  Priority,  PerMessageFl ag,  and 
Reci pi entlnfo. 

Validation  of  the  MPDUIdenti fier  is  for  further  study. 

For  relaying  messages,  Tracelnformation  will  be  examined  to  detect 
looping  route  problems.  Additional  validation  of  the  Tracelnformation 
is  for  further  study. 

The  actual  ReasonCodes  and  Di agnosticCodes  to  be  returned  in  the  case  of 
validation  failure  are  for  further  study. 


13.4.9  For  further  study 

Among  issues  reserved  for  further  study  are: 

1)  RTS  password  management 

2)  Billing 

3)  Quality  of  service 

4)  Diagnostic  information  in  support  of  operations 

5)  Intra-Domain  Routing 

6)  Multi-Vendor  Domains. 

RTS  password  management  is  currently  believed  to  be  a local  matter. 
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13.5  ERROR  REPORTING 


This  section  describes  appropriate  actions  to  be  taken  by  non-relaying 
domains  upon  receipt  of  protocol  elements  which  are  not  supported  in  this 
profile,  malformed  MPDUs,  unrecognized  0/R  Name  forms,  content  errors, 
errors  in  reports,  and  unexpected  values  for  protocol  elements. 


13.5.1  MPDU  Encoding 

The  MPDU  should  have  a context-specific  tag  of  0,  1,  or  2.  If  it  does 
not  have  one  of  these  tags,  it  is  not  possible  to  figure  out  who  originated 
the  message.  Therefore,  the  way  this  error  is  reported  is  a local  matter. 


13.5.2  Contents 

Once  delivery  to  the  UA  has  occurred,  it  is  not  possible  to  report  errors 
in  P2  information  to  the  originator.  In  addition,  it  seems  unreasonable 
to  insist  that  the  MTA  that  delivers  a message  ensures  that  the  P2  content 
of  the  message  is  okay.  As  a result,  the  handling  of  content  errors  is  a 
local  matter. 


13.5.3  Envelope 


13.5.3.1  Pragmatic  Constraint  Violations 

In  all  cases  of  pragmatic  constraint  violation,  a nondelivery  report 
should  be  generated  with  a ReasonCode  of  unableToTransfer,  and  a 
Di agnosticCode  of  inval idParameters.  Note:  it  would  be  desirable  for 

the  CCITT  to  add  a Di agnosticCode  of  pragmaticConstraintViolation  to 
allow  a more  meaningful  description  of  this  problem.  A request  for  this 
new  DiagnosticCode  has  been  submitted. 


13.5.3.2  Protocol  Violations 

If  not  all  required  protocol  elements  are  present,  a nondelivery  report 
with  a ReasonCode  of  unableToTransfer  and  a DiagnosticCode  of  inval idParameters 
should  be  generated.  Note:  it  would  be  desirable  for  the  CCITT  to  add  a 

DiagnosticCode  of  protocol  Violation  to  allow  a more  meaningful  description 
of  this  problem.  A request  for  this  new  DiagonsticCode  has  been  submitted. 

If  a protocol  element  is  expected  to  be  of  one  type,  but  is  encoded  as 
another,  then  a nondelivery  report  with  a ReasonCode  of  unabl eToTransfer 
and  a DiagnosticCode  of  inval idParameters  should  be  generated.  Note:  it 

would  be  desirable  for  the  CCITT  to  add  a DiagnosticCode  of  protocolViolation 
to  allow  a more  meaningful  description  of  this  problem.  A request  for 
this  new  DiagnosticCode  has  been  submitted. 
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13.5.3.3  0/R  Names 


The  domain  that  has  responsibility  for  delivering  a message  should  also 
have  the  responsibility  to  send  the  nondelivery  notification  if  the 
message  cannot  be  delivered.  Therefore,  each  domain  should  only  validate 
the  0/R  Names  of  recipients  with  responsibility  flags  set  to  TRUE.  In 
addition,  a nondelivery  notification  can  only  be  sent  if  the  originator's 
0/R  Name  is  valid. 

If  any  element  in  the  0/R  Name  is  unrecognized  or  if  the  CountryName, 

Admi ni strati onDomai nName,  and  one  of  PrivateDomai nName  and  OrganizationName 
are  not  all  present,  then  a nondelivery  report  should  be  generated  with  a 
ReasonCode  of  unabl eToTransfer,  and  a Di agnosticCode  of  unrecogni zedORName. 

If  the  message  can  be  delivered  even  though  the  ORName  is  invalid, 
delivery  is  a local  matter.  Note,  however,  that  if  the  message  is  delivered, 
the  invalid  ORName  might  be  propagated  through  the  X.400  system  (e.g.,  by 
forwardi  ng) . 

If  the  0/R  Name  has  all  of  the  appropriate  protocol  elements  and  the 
message  still  cannot  be  delivered  to  the  recipient,  the  following 
Di agnosticCodes  may  appear  in  the  nondelivery  report:  unrecogni zedORName, 

ambiguousORName,  and  uaUnavail able. 


13.5.3.4  Tracelnformation 

Since  non-relaying  domains  need  not  do  loop  suppression,  domains  with 
responsibility  for  delivering  the  message  need  not  be  concerned  about  the 
semantics  of  the  Tracelnformation,  that  is,  arrival  time  and  converted 
EncodedlnformationTypes  can  be  provided  to  the  UA  without  inspection  by 
the  MTAs  of  the  domain  as  long  as  the  Tracelnformation  is  properly  encoded 
according  to  X.409. 


13.5.3.5  Unsupported  X.400  Protocol  Elements 


The  protocol  elements  defined  in  X.400  but  unsupported  by  this  profile 
are:  the  deferredDel ivery  and  PerDomainBilateral Info  parameters  of  the 

UMPDUEnvel ope,  the  Expl i citConversi on  parameter  of  Recipientlnfo,  and  the 
al ternateReci pi entAl 1 owed  and  contentReturnRequest  bits  of  the  PerMessageFl ag. 
Appropriate  actions  are  described  below  for  domains  that  do  not  support 
the  protocol  elements. 


13.5.3.5.1  deferredDel ivery 

The  domain  shall  do  one  of  the  following: 

* del i ver  at  once, 

* hold  for  deferred  delivery, 

* return  a nondelivery  notification  with  a ReasonCode  of  unabl eToTransfer 

Note:  it  would  be  desirable  for  the  CCITT  to  add  a diagnostic  code  of 

noBi 1 ateral Agreement  to  allow  a more  meaningful  description  of 

this  problem.  A request  for  this  new  diagnostic  code  has  been 
submitted. 
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13.5.3.5.2  PerDomai nBi 1 at era! Info 


If  a domain  receives  this  service  element,  the  service  element  can  be 
ignored,  and  the  message  should  be  delivered  if  possible. 


13.5.3.5.3  Expl icitConversion 

If  Expl i ci tConversion  is  requested  the  message  should  be  delivered  if 
possible.  That  is,  if  the  UA  is  registered  to  accept  the  EncodedlnformationTypes 
of  the  message,  then  the  message  should  be  delivered  even  though  the 
domain  could  not  perform  the  requested  conversion.  If  delivery  is  not 
possible,  then  a nondelivery  report  should  be  generated  with  a ReasonCode 
of  conversionNotPerformed  with  no  DiagnosticCode. 


13.5.3.5.4  alternateRecipientAI lowed 

If  a domain  receives  this  service  element  the  service  element  can  be 
ignored,  and  this  message  should  be  delivered  if  possible. 


13.5.3.5.5  contentReturnRequest 

If  a domain  receives  this  service  element,  the  service  element  can  be 
ignored,  and  the  message  should  be  delivered  if  possible. 


13.5.3.6  Unexpected  Values  for  INTEGER  Protocol  Elements 

There  are  three  INTEGERS  in  the  PI  Envelope.  Appropriate  actions  are 
described  below  for  domains  receiving  unexpected  values  for  Priority, 
Expl i ci tConversion , and  ContentType. 


13.5.3.6.1  Priority 

Additional  values  for  Priority  have  been  suggested  by  at  least  one  group 
of  implementors  as  upward  compatible  changes  to  the  X.400  Recommendations. 
Therefore,  if  a domain  receives  an  unexpected  value  for  Priority,  and 
this  value  is  greater  than  one  byte  in  length,  a nondelivery  report  should  be 
generated  with  a ReasonCode  of  unableToTransfer  and  DiagnosticCode  of 
inval idParameters.  If  the  value  is  less  than  or  equal  to  one  byte,  the  domain 
can  either  generate  a nondelivery  report  as  previously  specified  or  default 
the  Priority  to  normal  and  deliver  the  message. 


13.5.3.6.2  ExplicitConversion 

The  message  should  be  delivered  if  possible.  That  is,  if  the  UA  is 
registered  to  accept  the  EncodedlnformationTypes  of  the  message,  then  the 
message  should  be  delivered  even  though  the  domain  could  not  perform  the 
requested  conversion.  If  delivery  is  not  possible,  then  a nondelivery 
report  should  be  generated  with  a ReasonCode  of  conversionNotPerformed 
with  no  DiagnosticCode. 
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13.5.3.6.3  ContentType 


If  the  ContentType  is  not  supported,  then  a nondelivery  report  should  be 
generated  with  a ReasonCode  of  unabl eToTransfer,  and  a Di agnosti cCode  of 
i nval  idParameters.  Note:  it  would  be  desirable  for  the  CCITT  to  add  a 

Di agnosticCode  of  contentNotSupported  to  allow  a more  meaningful  description 
of  this  problem.  A request  for  this  new  Di agnosticCode  has  been  submitted. 


13.5.3.7  Additional  Service  Elements 

In  the  absence  of  bilateral  agreements  to  the  contrary,  receipt  of  privately 
tagged  elements  and  protocol  elements  in  addition  to  those  defined  in  X.400 
will  result  in  a nondelivery  report  with  a ReasonCode  of  unableToTransfer 
and  a Di  agnosticCode  of  i nval idParameters. 


13.5.4  Reports 

There  is  no  mechanism  for  returning  a delivery  or  status  report  due  to 
errors  in  the  report  itself.  Therefore  the  handling  of  errors  in  reports 
is  a local  matter. 


13.6  MHS  USE  OF  DIRECTORY  SERVICES 

Recommendation  X.400  recognizes  the  need  of  MHS  users  for  a number  of 
directory  service  elements.  Directory  service  elements  are  intended  to 
assist  users  and  their  UAs  in  obtaining  information  to  be  used  in  submitting 
messages  for  delivery  by  the  MTS.  The  MTS  may  also  use  directory  service 
elements  to  obtain  information  to  be  used  in  routing  messages.  Some 
functional  requirements  of  directories  have  been  identified  and  are  listed 
bel ow. 

1.  Verify  the  existence  of  an  0/R  name. 

2.  Return  the  0/R  address  that  corresponds  to  the  0/R  name  presented. 

3.  Determine  whether  the  0/R  name  presented  denotes  a user  or  a 
distribution  list. 

4.  Return  a list  of  the  members  of  a distribution  list. 

5.  When  given  a partial  name  return  a list  of  0/R  name  possibilities. 

6.  Allow  users  to  scan  directory  entries. 

7.  Allow  users  to  scan  directory  entries  selectively. 

8.  Return  the  capabilities  of  the  entity  referred  to  by  the  0/R  name. 

9.  Drovide  maintenance  functions  to  keep  the  directory  up-to-date. 
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In  addition  to  functionality,  a number  of  operational  aspects  must  be 
considered.  These  include  user-friendliness,  flexibility,  availability, 
expandability,  and  reliability. 

Currently,  these  aspects  of  directory  service  elements  and  procedures  are 
under  study  by  both  the  CCITT  and  the  ISO.  Both  organizations  are 
committed  to  the  development  of  a single  Directory  Service  specification 
for  use  by  MHS  and  all  other  OSI  based  applications. 

Given  the  incomplete  nature  of  the  ongoing  activities  within  the  CCITT 
and  the  ISO,  no  implementation  details  will  now  be  provided  for  MHS  use 
of  Directory  Services.  Implementation  agreements  for  MHS  Use  of  Directory 
Services  will  be  issued  when  current  activities  within  the  CCITT  and  the 
ISO  are  stable. 

It  is  recognized  that  these  agreements  enable  a wide  variety  of  naming 
and  addressing  attributes  (see  section  13.3.5.3.3  ORName  Protocol  Elements) 
wherein  each  PRMD  may  adopt  particular  routing  schemes  within  its  domain. 
These  agreements  make  no  attempt  to  recommend  a standard  practice  for 
electronic  mail  addressing. 

Inter-PRMD  addressing  may  be  secured  according  to  practices  outside  the 
scope  of  these  agreements,  such  as: 

° manual  directories 
° on-line  directories 
0 ORName  address  specifications 
° ORName  address  translation 

Further,  each  PRMD  may  adopt  naming  and  addressing  schemes  wherein  the 
user  view  may  take  a form  entirely  different  from  the  attributes  reflected 
in  section  13.3.4.2.2  herein.  And,  each  PRMD  may  have  one  user  view  for 
the  originator  form  and  another  for  the  recipient  form,  and  perhaps  other 
forms  of  user  addressing.  In  some  cases  (e.g.,  receipt  not ifocat ion ) these 
user  forms  must  be  preserved  within  the  constraints  of  these  implementation 
agreements.  However,  mapping  between  one  PRMD  user  form  to  another  PRMD 
user  form,  via  the  X.400  ORName  attributes  of  these  agreements,  is  outside 
the  scope  of  these  agreements. 


13.7  CONFORMANCE 

In  order  to  ensure  that  products  conform  to  these  implementation  agreements, 
it  is  necessary  to  define  the  types  and  degrees  of  conformance  testing  products 
that  must  pass  before  they  may  be  classified  as  conformant.  This  section 
defines  the  conformance  requirements  and  provides  guidelines  for  the 
interpretation  of  the  results  from  this  type  of  testing. 
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In  order  to  achieve  a minimum  level  of  confidence  in  the  conformance  of  a 
product,  the  most  basic  requirements  a product  must  meet  to  be  classified 
as  conformant  to  these  agreements  are  provided.  This  minimal  set  was  defined 
to  ensure  that  the  resulting  MHS  network  will  provide  a reasonable  inter- 
personal messaging  facility  to  its  users  while  still  giving  a reasonable 
assurance  that  conforming  products  can  soon  be  made  available.  In 
addition,  the  full  conformance  requirements  for  products  implementing  all 
aspects  of  X.400  Messaging  governed  by  these  agreements  are  provided. 

This  section  is  incomplete  and  will  be  enhanced  in  future  versions  of 
this  agreement.  Later  versions  will  reflect  the  problems  of  conformance 
testing  and  will  outline  specific  practices  and  recommendations  to  aid 
the  development  of  conformance  tests  and  procedures. 


13.7.1  Definition  of  Conformance 


For  this  section,  the  term  conformance  is  defined  by  the  following: 

1.  The  tests  indicated  for  this  section  are  intended  to  establish  a 
high  degree  of  confidence  in  a statement  that  the  implementation 
under  test  (IUT)  conforms  (or  does  not  conform)  to  the  agreements 
of  th is  section . 

2.  Conformance  to  a service  element  means  that  the  information  associated 
with  the  service  element  is  made  accessible  to  the  user  (person  or 
process)  whenever  this  agreement  says  that  this  information  should  be 
available. 

Accessible  means  that  information  must  be  provided  describing  how  a 
user  (person  or  process): 

a)  causes  appropriate  information  to  be  displayed,  or 

b)  causes  appropriate  information  to  be  obtained. 

3.  Conformance  to  PI,  P2,  and  RTS  as  part  of  an  X.400  OSI  application 
requires  that  only  the  external  behavior  of  that  OSI  system  adheres 
to  the  relevant  protocol  standards. 

In  order  to  achieve  conformance  to  this  section,  it  is  not  required 
that  the  inter-layer  interfaces  be  available  for  testing  purposes. 

4.  Conformance  to  the  protocols  requires: 

a)  that  MPDUs  correspond  to  instances  of  syntactically  correct  data 
un  its, 

b)  MPDUs  in  which  the  data  present  in  the  fields  and  the  presence  (or 
absence)  of  those  fields  is  valid  in  type  and  semantics  as  defined 
in  X.400,  as  qualified  by  this  profile, 

c)  correct  sequences  of  protocol  data  units  in  responses  (resulting 
from  protocol  procedures). 
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5.  Statements  regarding  the  conformance  of  any  one  implementation  to 
this  profile  are  not  complete  unless  a Protocol  Implementation 
Conformance  Statement  (PICS)  is  supplied. 

6.  The  term  "Implementation  Under  Test"  (IUT)  is  interchangeable  with 
the  term  "system"  in  the  definition  of  conformance,  and  may  refer  to: 

a)  a domain,  which  may  be  one  or  more  MTA's  with  co-located  or  remote 
UA's, 

b)  a single  instance  of  an  MTA  and  co-located  UA  with  X.400  (PI,  P2, 
RTS  and  session)  software, 

c)  a relaying  product  with  PI,  RTS  and  session  software, 

d)  a gateway  product. 

7.  Tests  for  conformance  apply  independently  to: 

a)  origination, 

b)  reception, 

c)  relaying. 


13.7.2  Conformance  Requirements 

Conformance  to  this  specification  requires  that  all  the  services  listed  as 
supported  in  sections  13.3  and  13.4  of  these  agreements  are  supported  in  the 
manner  defined,  in  either  the  CCITT  X.400  Recommendations  or  these  agreements. 

It  is  the  intention  to  adopt,  where  and  when  appropriate  the  testing 
methodology  and/or  the  abstract  test  scenarios  currently  being  defined  by 
the  CCITT  X.400  Conformance  Group.  However  it  is  recognized  that  formal 
CCITT  Recommendations  relating  to  X.400  Conformance  Testing  will  not  be 
available  until  1988. 


13.7.2.1  Initial  Conformance 

This  section  is  intended  to  provide  guidelines  to  vendors  who  envisage 
having  X.400  products  available  prior  to  any  formal  mechanism,  or 
'Conformance  Test  Center'  being  made  accessible  that  would  allow  for 
conformance  to  this  product  specification  to  be  tested. 
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It  is  feasible  that  vendors  and  carriers  will  want  to  enter  bilateral 
test  agreements  that  will  allow  for  initial  trials  to  be  carried  out  for 
the  purposes  of  testing  initial  interworking  capabilities.  It  is  equally 
feasible  that  for  the  purposes  of  testing  interoperabil  ity , only  a subset 
of  this  specification  will  initially  be  tested.  Therefore  it  is  recommended 
that  the  following  subset  of  total  information  be  made  accessible  to 
allow  for  meaningful  testing. 

Note:  By  claiming  conformance  to  this  subset  of  information  the  vendor 

or  carrier  cannot  claim  conformance  to  this  entire  specification. 


There  are  two  aspects  to  the  requirements,  interworking  and  service,  as 
described  in  the  following  sections. 

13.7.2.1.1  Interworking 

The  interworking  requirements  for  conformance  implies  that  tests  be  done 
to  check  for  the  syntax  and  semantics  of  protocol  data  elements  for  a 
system  as  defined  by  their  classifications  (i.e.,  X,  H,  G,  R,  and  M). 

For  an  origination  system,  this  implies  that  the  protocol  elements 
generated  must  be  correct.  For  a relay  system,  the  correct  protocol 
elements  should  be  relayed  as  appropriate.  And  for  a recipient  system,  a 
message  with  correct  protocol  elements  must  not  be  rejected  where  appropriate. 


13.7.2.1.2  Serv ice 

For  information  available  to  the  recipients  via  the  IPMessage  Heading  and 
Body,  the  following  should  be  made  accessible: 

- IPMessage  ID  - only  the  PrintableString  portion  of  the  IPMessageld 
needs  to  be  accessible. 

« 

- subject 

- primaryRecipients 

- copyRecip  ients 

- bl indCopyRec ipients 

- authorizingllsers 

- originator 

- inReplyTo 

- replyTollsers 

- importance 

- sensitivity 

- IA5Text  BodyPart 
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14.  DIRECTORY  SERVICES  PROTOCOLS 


The  directory  services  protocols'  implementation  specifications  are  being 
prepared  by  the  DS  SIG. 


15.  PERFORMANCE 


To  be  completed. 


16.  SECURITY 


To  be  completed. 
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APPENDIX  A:  INTERPRETATION  OF  SERVICE  ELEMENTS 


The  work  on  service  element  definitions  is  limited  to  those  that  are 
defined  as  'supported'  in  section  13.3  of  this  specification.  Furthermore 
it  is  not  the  intent  of  this  section  to  define  how  information  should  be 
made  available  or  presented  to  a MHS  user,  nor  is  it  intended  to  define 
how  individual  vendors  should  design  their  products.  In  addition, 
statements  on  conformance  to  a specific  service  element  and  the  allocation 
of  error  codes  that  are  generated  as  a result  of  violations  of  the  service 
should  be  defined  in  the  sections  on  conformance  and  errors  as  part  of 
the  main  product  specification.  The  main  objective  is  to  provide 
clarification,  where  required,  on  the  functions  of  a service  element,  and 
in  particular  what  the  original  intent  of  the  Recommendations  were. 


SERVICE  ELEMENTS 

The  following  Service  Elements  defined  .in  X.400  have  been  examined  and 
require  further  text  to  be  added  to  their  definitions  to  represent  the 
proposed  implementation  of  these  service  elements  by  the  X.400  SIG. 

The  service  element  clarifications  are  to  be  taken  in  the  context  of  this 
prof i 1 e. 

Service  elements  not  referenced  in  this  section  are  as  defined  in  X.400. 


PROBE 

A PRMD  need  not  generate  probes. 

If  a probe  is  addressed  to  and  received  by  a PRMD,  the  PRMD  must  respond 
with  a Delivery  Report  as  appropriate  at  the  time  the  probe  was  processed. 


DEFERRED  DELIVERY 

In  the  absence  of  bilateral  agreements  to  the  contrary.  Deferred  Delivery 
and  Deferred  Delivery  Cancellation  are  local  matters  ( i . e . , confined  to 
the  originating  domain)  and  need  not  be  provided. 

The  extension  of  Deferred  Delivery  beyond  the  boundaries  of  the  initiating 
domain  is  via  bilateral  agreement  as  specified  in  Section  3. 4. 2.1  of  X .411 . 


Content  Type  Indication 

It  is  requi  red  that  both  an  originating  and  recipient  domain  be  able  to 
support  P2  content  type.  The  ability  for  domains  to  be  able  to  exchange 
content  types  other  than  P2  will  depend  on  the  existence  of  bilateral  or 
multi-lateral  agreements. 
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Original  Encoded  Information  Types  Indication 

It  is  required  that  both  an  originating  and  recipient  domain  be  able  to 
support  IA5  text.  Support  for  other  encoded  information  types,  for  the 
purposes  of  message  transfer  between  domains,  will  depend  on  the  existence 
of  bilateral  or  multi-lateral  agreements. 

The  use  of  the  'unspecified'  form  of  encoded  information  type  should  only 
be  used  when  the  UMPDU  content  represents  an  SR-UAPDU  or  contains  an  auto- 
forwarded  IM-UAPDU. 

The  original  encoded  information  type  of  a message  is  not  meaningful 
unless  a message  is  converted  en  route  to  the  recipient.  These  agreements 
support  only  IA5  text,  which  should  not  undergo  conversion.  The  original 
encoded  information  types  should  be  made  accessible  to  the  recipient  for 
upward  compatibility  with  the  use  of  non-IA5  text  message  body  parts. 


Registered  Encoded  Information  Types 

A UMPDU  with  an  'unspecified'  value  for  Original  Encoded  Information  Type 
shall  be  delivered  to  the  UA. 


Delivery  Notification 

The  UAContentID  may  be  used  by  the  recipient  of  the  delivery  notification 
for  correlation  purposes. 


Disclosure  of  Other  Recipients 

This  service  is  not  made  available  by  originating  MTAE's  to  UAE's,  but 
must  be  supported  by  relaying  and  recipient  MTAE's. 

By  supporting  the  disclosure  of  other  recipients  the  message  recipient 
can  be  informed  of  the  0/R  names  of  the  other  recipient(s)  of  the  message, 
as  defined  in  the  PI  envelope  in  addition  the  0/R  Descriptors  within  the 
P2  header. 

These  agreements  do  not  support  initiation  of  disclosure  of  other 
recipients,  but  the  information  associated  with  it  should  be  made  accessible 
to  the  recipient  for  upward  compatibility  with  support  for  the  initiation 
of  this  service  element. 


Typed  Body 

As  defined  in  X.400  with  the  addition  of  the  Private  Body  Types  that  are 
to  be  supported.  At  present  there  is  no  mechanism  provided  within  X.420 
that  would  allow  you  to  respond  to  reception  of  an  unsupported  body  type. 

Action  taken  in  this  situation  is  a local  matter. 
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Blind  Copy  Recipient  Indication 


It  should  be  considered  that  the  recipient's  UA  acts  on  behalf  of  the 
recipient,  and  therefore  may  choose  to  disclose  all  BCC  recipients  to 
each  other.  Therefore  it  is  the  responsibility  of  the  originating  domain 
to  submit  two  or  more  messages,  depending  on  whether  or  not  each  BCC  should 
be  disclosed  to  each  other  BCC. 


Auto-Forwarded  Indication 


A UA  may  choose  not  to  forward  a message  that  was  previously  auto-forwarded. 
In  addition  there  is  no  requirement  for  an  I PM  UA  that  does  not  support 
non-receipt  or  receipt  notification  to  respond  with  a non-receipt 
notification  when  a message  is  auto-forwarded. 


Primary  and  Copy  Recipients  Indication 

It  is  required  that  at  least  one  primary  recipient  be  specified;  however, 
for  a forwarded  message  this  need  not  be  present.  The  recipient  tIA  should 
be  prepared  to  accept  no  primary  and  copy  recipients  to  enable  future 
interworking  with  Teletex,  Fax,  etc. 


Sensitivity  Indication 

A message  originator  should  make  no  assumptions  as  to  the  semantic 
interpretation  by  the  recipients  UA  regarding  classifications  of  sensitivity. 
For  example,  a personal  message  may  be  printed  on  a shared  printer. 


Reply  Request  Indication 

In  requesting  this  service  an  originator  may  additionally  supply  a date 
by  which  the  reply  should  be  sent  and  a list  of  the  intended  recipients 
of  the  reply.  If  no  such  list  is  provided  than  the  initiator  of  the  reply 
sends  the  reply  to  the  originator  of  the  message  and  any  recipients  the 
reply  initiator  wishes  to  include.  The  replytoUsers  and  the  replyBy  date 
may  be  specified  without  any  explicit  reply  being  requested.  This  may  be 
interpreted  by  the  recipient  as  an  implicit  reply  request.  Note  that  for 
an  auto-forwarded  message  an  explicit  or  implicit  reply  request  may  not 
be  meani  ngful . 


Body  Part  Encryption 

The  original  encoded  information  type  indication  includes  the  encoded 
information  type(s)  of  message  body  parts  prior  to  encryption  by  the 
originating  domain.  The  ability  for  the  recipient  domain  to  decode  an 
encrypted  body  part  is  a local  matter.  Successful  use  of  this  facility 
can  only  be  guaranteed  if  there  exists  bilateral  agreements  to  support 
the  exchange  of  encrypted  body  parts. 
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Forwarded  IP-message  Indication 


The  following  use  of  the  original  encoded  information  type  in  the  context 
of  forwarded  messages  is  clarified: 

* If  forwarding  a private  message  body  part  the  originator  of  the 
forwarded  message  shall  set  the  original  encoded  information 
types  in  the  PI  envelope  to  undefined  for  that  body  part. 

* The  encoded  information  types  of  the  message  being  forwarded 
should  be  reflected  in  the  new  original  encoded  information 
types  being  generated. 

* See  Appendix  B on  recommended  practices  for  the  use  of  the  delivery 
information  as  part  of  Forwarded  IP-message. 


Multipart  Body 

It  is  the  intent  of  multipart  bodies  to  allow  for  the  useful  and  meaningful 
structuring  of  a message  that  is  constructed  using  differing  body  part 
types.  For  example,  it  is  not  recommended  that  a message  made  up  of  only 
IA5  text  should  be  represented  as  a number  of  IA5  body  parts,  each  one 
representing  a paragraph  of  text. 
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APPENDIX  B:  RECOMMENDED  PRACTICES 


B.l  RECOMMENDED  PRACTICES  IN  P2 

a)  ORDescriptor 

Vendors  following  the  NBS/OSI  Workshop  guidelines  shall,  whenever 
possible,  generate  the  ORName  portion  of  an  ORDescriptor  in  ALL 
IPM  Heading  fields. 

b)  ForwardedIPMessage  BodyParts 

ForwardedIPMessage  BodyParts  should  be  nested  no  deeper  than 
eight.  There  is  no  restriction  on  the  number  of  ForwardedIPMessage 
BodyParts  at  any  given  depth. 

c)  Del iverylnformation 

It  is  strongly  recommended  that  Del iverylnformation  be  supplied  in 
both  forwarded  and  autoforwarded  message  body  parts.  Del iverylnformation 
is  useful  when  a message  has  multiple  forwarded  message  body  parts 
because  without  it,  the  EncodedlnformationType(s)  of  the  component 
forwarded  messages  cannot  be  deduced  easily.  Del iverylnformation 
is  useful  for  autoforwarded  messages  because  the  EncodedlnformationType 
of  an  autoforwarded  message  is  "unspecified"  and  the  Encodedlnformati on- 
Type(s)  of  the  message  cannot  be  determined  easily  without  it. 

Absence  of  the  EncodedlnformationType(s)  makes  it  difficult  for 
a UA  to  easily  determine  whether  the  message  can  be  rendered. 

B .2  RECOMMENDED  PRACTICES  IN  RTS 

a)  The  calling  party  Network  address  should  be  used  for  MTA  validation 
rather  than  the  mTAName  and  password.  The  calling  party  address 
validation  method' is  preferable  since  the  recover  function  (in 
S-CONNECT)  does  not  allow  the  specification  of  mTAName  and  password. 

b)  In  the  case  where  S-U-ABORT  indicates  a temporaryProblem,  re-establishment 
of  the  session  should  not  be  attempted  for  a "sensible"  time  period 
(typically  not  less  than  five  minutes). 

In  instances  where  this  delay  is  not  required  or  necessary,  report 
a local SystemProblem. 

c)  S-U-EXCEPTION-REPORT  reason  codes  can  be  interpreted  as  follows: 

• receiving  ability  jeopardized  (value  1) 

Possible  meaning:  The  receiving  RTS  knows  of  an  impending  system  shutdown. 

• local  ss-tJser  error  (value  5) 

Possible  meaning:  <for  further  study> 

• unrecoverable  procedure  error  (value  6) 

Possible  meaning:  the  current  activity  is  NOT  recoverable. 
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• non  specific  error  (value  0) 

Possible  meaning:  <for  further  study> 

# sequence  error  (value  3):  The  S-ACTIVITY-RESUME  request  specified 

a minor  synchronization  point  serial  number  which  does  not  match 
the  checkpoint  data. 


B.3  RECOMMENDED  PRACTICES  WITH  X.409 

The  following  practices  are  recommended  for  use  with  X.409. 

a.  The  maximum  length  of  a primitive  data  element  is  256. 

b.  Bit  Strings  should  be  built  using  primitive  form.  The  constructor  form 
should  not  be  used  except  in  the  case  of  very  long  Bit  Strings 

(e.g. , 63Fax  or  Voice) . 

c.  All  defined  bits  of  a Bit  String  should  be  present. 

• Note  that,  in  accordance  with  X.409,  defined  bits  need  not  be  present; 
missing  bits  are  assumed  to  be  zero. 

• To  ensure  upward  compatibility.  Bit  Strings  of  excess  length  must  also 
be  allowed;  the  excess  bits  are  ignored. 

d.  The  maximum  definite  length  should  be  ( 2**32 ) -1 . <For  further  study> 

e.  It  is  intended  that  implementations  support  upwardly  compatible 
changes  to  X.409,  as  defined  in  Version  3 of  the  X. 400-Series 
Implementor's  Guide,  but  no  guarantees  will  be  made  about  initial 
impl ementati ons. 

f.  The  concrete  encoding  of  ANY  must  be  a valid  X.409  type,  and  can  only 
be  omitted  if  it  is  an  OPTIONAL  element  in  a SET  or  SEQUENCE. 


B .4  RECOMMENDED  PRACTICES  FOR  ORName 

Table  13.3.8  stipulates  that  the  StandardAttributeList  must  contain  either 
Pri vateDomai nName  or  Organization  Name.  It  is  recommended  that,  for  both 
originator  and  recipients  in  a private  domain,  the  Pri vateDomai nName 
field  be  used. 
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It  is  recommended  that  there  should  be  a DDA  to  be  used  in  addresing  UAs 
in  existing  mail  systems,  in  order  to  curtail  the  proliferation  of 
different  types  of  DDAs  used  for  the  same  purpose.  The  syntax  of  this 
DDA  conforms  to  the  CCITT  Pragmatic  Constraints,  and  thus  has  a maximum 
value  length  of  128  octets  and  a type  length  of  8 octets,  each  of  type 
Printable  String.  One  occurrance! 

This  DDA  has  the  type  name  "ID"  (in  uppercase).  It  contains  the  unique 
identifier  of  the  UA  used  in  addressing  within  the  domain.  This  DDA  is 
to  be  exclusively  used  for  routing  within  the  destination  domain  (i.e. 
once  routed  to  that  domain  via  the  mandatory  components  of  the  Standard 
Attribute  list);  any  other  components  of  the  Standard  Attribute  list  may 
be  provided.  If  they  conflict  delivery  is  not  made. 

The  contents  of  the  valve  parameter  need  not  be  validated  in  the  originating 
domain  or  any  relaying  domain,  but  simply  transferred  intact  to  the  next 
MTA/domain. 
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APPENDIX  C:  RENDITION  OF  IA5Text  AND  T61String  CHARACTERS 


C.l  GENERATING  AND  IMAGING  IA5Text 

The  characters  that  may  be  used  in  an  IA5String  are  the  graphic  characters 
(including  Space),  control  characters  and  Delete  of  the  IA5  character 
repertoire  ISO  646. 

The  graphic  characters  that  may  be  used  with  a guaranteed  rendition  are 
those  related  with  positions  2/0  to  2/2,  2/5  to  3/15,  4/1  to  5/10,  5/15 
and  6/1  to  7/10  in  the  basic  7-bit  code  table. 

The  other  graphic  characters  may  be  used  but  have  no  guaranteed  rendition. 

The  control  characters  that  may  be  used  but  have  no  guaranteed  effect  are 
a subset  consisting  of  the  format  effectors  0/10  (LF),  0/12  (FF)  and  0/13 
(CR)  provided  they  are  used  in  one  of  the  following  combinations: 

CR  LF  to  start  a new  line 

CR  FF  to  start  a new  page  (and  line) 

LF  ..  LF  to  show  empty  lines  (always  after  one  of  the  preceding 

combi  nations) . 

The  other  control  characters  or  the  above  control  characters  in  different 
combinations  may  be  used  but  have  no  guaranteed  effect. 

The  character  Delete  may  occur  but  has  no  guaranteed  effect. 

The  IA5String  in  a P2  IA5Text  BodyPart  represents  a series  of  lines 
which  may  be  divided  into  pages.  Each  line  should  contain  from  0 to  80 
graphic  characters  for  guaranteed  rendition.  Longer  lines  may  be 
arbitrarily  broken  for  rendition.  Note  that  X.408  states  that  for 
conversion  from  IA5Text  to  Teletex,  the  maximum  line  length  is  77  characters. 


C.2  GENERATING  AND  IMAGING  T61String 
For  further  study. 


115 


APPENDIX  D:  FTAM  DOCUMENT  TYPES 


Part 

1: 

Document 

Types 

Part 

2: 

Constraint  Sets 

Part 

3: 

Abstract 

Syntaxes 

Part 

4: 

Transfer 

Syntaxes 

Part  1:  Document  Types 


Entry  Number:  NBS-1 

Do£ument_T  y£e_Name_: 

)lS0  registration-authority  NBS  FTAM(  ) document(6)  UNDEF(O)  ( 
Document  D£S£rjp£o£  ^a]_ue : unstructured  binary  file 


Do^u  m ent_S£man  t_  ks : 

The  document  consists  of  a single  data  unit.  The  data  unit  consists  of 
an  unbounded  sequence  of  data  elements.  Each  data  element  is  an  octet  string. 
Note:  The  boundaries  between  transferred  data  elements  are  not  maintained 

by  the  filestore. 

Scope_  and_  F_ie_l  d_  £f_A£p_l_i£at_i£nj_ 

This  document  type  defines  the  contents  of  a file  for  storage  and  for 
transfer  using  FTAM. 

£on_stra_  int_S£t_N£me_: 

{ISO  standard  8571  constraint  set  name(5)  unstructured( 1)  ( 

Abstract  _Syn£ax_: 

The  abstract  syntax  of  each  Data  Element  is  an  instance  of  the  ASN.l  data 
type  Octetstring. 

Ab£t_ra£t_S^n£ax_  Name£ 

{ISO  registration-authority  NBS  FTAM(  ) abstract  syntax(2)  NBS-ASl(O)  ( 
Transfer  Syntax: 

An  implementation  supporting  this  abstract  syntax  shall  support  a transfer 
syntax  for  each  data  element  obtained  by  applying  the  ASN.l  Basic  Encoding 
Rules  (ISO  8825)  to  the  data  element  and  concatenating  the  resulting 
octets. 

Note:  This  transfer  syntax  is  not  self  delimiting. 

Implementations  may  optionally  support  other  named  transfer  syntaxes  for 
this  abstract  syntax. 

T_ra_ns_f£r_Sy_n£ax_  Namej_ 

{ISO  reg istrat  ion-author  ity  NBS  FTAM(  ) transfer  syntax(3)  NBS-TS 1 ( 0 ) } 
Concatenat  ion : 


Concatenation  of  this  type  with  itself  is  possible,  and  produces  a document 
of  the  same  type  consisting  of  one  data  unit  which  is  the  concatenation  of 
the  octet  string(s)  from  one  file  with  the  octet  string(s)  of  the  other  file. 
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Note:  The  boundary  of  the  original  octet  string(s)  is  no  longer  visible. 

S_  imp]_  if  i£at_  ion£: 

A document  of  this  type  cannot  be  accessed  as  any  other  document  type. 
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Entry  Number:  NBS-2 


£o£ument_Type_  _Namej_ 

{ISO  reg  istrat  ion-author ity  NBS  FTAM(  ) document(6)  VARCRLF(1)| 
D^o£ument_De_S£M pt_0£  £aj_u£:  un st ruct u red  text  file 

Document  Semantics: 


The  document  consists  of  a single  data  unit.  The  data  unit  consists  of 
an  unbounded  sequence  of  data  elements.  Each  data  element  is  an  IA5String. 
The  last  two  characters  of  each  data  element  are  carriage  return  followed 
by  line  feed.  Neither  the  character  carriage  return  nor  the  character 
line  feed  may  appear  elsewhere  in  the  data  element. 

Note:  The  boundaries  between  transferred  data  elements  are  not  maintained 

by  the  filestore. 

Scope.  and_  Mel  d_  of _A£pJ_ i£a£ i on j_ 

The  document  type  defines  the  contents  of  a file  for  transfer  using  FTAM. 

Note  that  this  document  type  should  only  be  used  for  transferring  entire 
text  files  in  the  case  where  NBS-4  is  not  supported.  It  has  an  implicit 
structure  which  allows,  for  example,  text  files  stored  in  UNIX  format 
(lines  terminated  by  LF)  to  be  converted  to  a format  in  which  lines  are 
terminated  by  CR  followed  by  LF  and  vice  versa. 

£on_stxa_  int_Set_Nam£: 

{ISO  standard  8571  constraint  set  name(5)  unstructured( 1)  [ 

Abstract  Syntax: 

The  abstract  syntax  of  each  Data  Element  is  an  instance  of  the  ASN.l  data 
type  IA5String. 

A_bs_t_ra£t_S£n£ax_  Namej_ 

{iSO  registration-authority  NBS  FTAM(  ) abstract  syntax(2)  NBS-AS1(0)| 
_Tran_sf£r_S^n£a_x: 

An  implementation  supporting  this  abstract  syntax  shall  support  a transfer 
syntax  (for  each  data  element  obtained  by  applying  the  ASN.l  Basic  Encoding 
Rules  (ISO  8825)  to  the  data  element  and  concatenating  the  resulting 
octets. 

Note:  This  transfer  syntax  is  not  self-delimiting. 

Implementations  may  optionally  support  other  named  transfer  syntaxes  for 
this  abstract  syntax. 
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l>ans_f e_r_S^nt_a_x  N_amej_ 

| ISO  registration-authority  NBS  FTAM(  ) transfer  syntax(3)  NBS-TSl(O)  [ 
£oncatenat  jon_:_ 

Concatenation  of  this  type  with  itself  is  possible,  and  produces  a document 
of  the  same  type  consisting  of  one  data  unit  which  is  the  concatenation 
of  the  octet  string(s)  from  one  file  with  the  octet  string(s)  of  the 
other  file. 

Note:  The  boundary  of  the  original  octet  string(s)  is  no  longer  visible. 

impj_  if.  ic_at_  i onj_ 

A document  of  this  type  can  be  accessed  as  a document  of  type  NBS-1  by 
specifying  a document  type  of  NBS-1  in  the  Contents  Type  parameter  of  the 
F-OPEN  request,  and  limiting  access  context  to  US  on  F-READ. 
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Entry  Number: 


NBS-3 


_Do£ument_Ty_pe_  Name£ 

{ISO  reg  istrat  ion-authority  NBS  FTAM(  ) document(6)  8859VARCRLF( 2) | 


£o£umen_t_De_S£r_ipt_o_r  Va]_ue : unstructured  text  file 

Document  Semantics: 


The  document  consists  of  a single  data  unit.  The  data  unit  consists  of 
an  unbounded  sequence  of  data  elements.  Each  data  element  is  an  8859String. 
The  last  two  characters  of  each  data  element  are  carriage  return  followed 
by  line  feed.  Neither  the  character  carriage  return  nor  the  character 
line  feed  may  appear  elsewhere  in  the  data  element. 

Note:  The  boundaries  between  transferred  data  elements  are  not  maintained 

by  the  filestore. 


S_cop£  and_  F_ie_ld_  £f _A£pJ_ i£a£ i£n£ 

The  document  type  defines  the  contents  of  a file  for  transfer  using  FTAM. 

Note  that  this  document  type  should  only  be  used  for  transferring  entire 
text  files  in  the  case  where  NBS-5  is  not  supported.  It  has  an  implicit 
structure  which  allows,  for  example,  text  files  stored  in  UNIX  format 
(lines  terminated  by  LF)  to  be  converted  to  a format  in  which  lines  are 
terminated  by  CR  followed  by  LF  and  vice  versa. 

Con_s  tr£  i£t_Set_Name_: 

{ISO  standard  8571  constraint  set  name(5)  unstructured( 1)  [ 
Abst£a£t_S£n£ax_: 

The  abstract  syntax  of  each  data  element  is  an  instance  of  the  data  type 
8859String. 

Ab£t£a£t_S£n tax_  N_ame£ 

{ISO  registration-authority  NBS  FTAM(  ) abstract  syntax(2)  NBS-ASl(O)  ) 
T>£n£f£r_S£n£ax_: 

An  implementation  supporting  this  abstract  syntax  shall  support  a transfer 
syntax  for  each  data  element  obtained  by  applying  the  ASN.l  Basic  Encoding 
Rules  (ISO  8825)  to  the  data  elements  and  concatenating  the  resulting 
octets. 

Note:  this  transfer  syntax  is  not  self-delimiting. 

Implementations  may  optionally  support  other  named  transfer  syntaxes  for 
this  abstract  syntax. 
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Tran s_f  er_S^n ta_x  _Namej_ 

|lSO  registration-authority  NBS  FTAM(  ) transfer  syntax(3)  NBS-TS1 ( 0 ) } 
Concatenat  ion : 


Concatenation  of  a document  of  this  type  with  another  document  of  this 
type  is  possible  and  produces  a document  of  the  same  type  consisting  of 
one  data  unit  which  is  the  concatenation  of  the  octetstring(s)  of  one 
file  with  the  octetstring( s)  of  the  other  file. 

Note:  The  boundary  of  the  original  Octetstring  is  no  longer  visible. 

S_  imp]_  if  ic_at_  |onj_ 

A document  of  type  NBS-3  can  be  accessed  as  a document  of  type  NBS-1  by 
specifying  a document  type  of  NBS-1  in  the  Contents  Type  parameter  of  the 
F-OPENrequest , and  limiting  access  context  to  US  on  F-READ. 
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Entry  Number:  NBS-4 

Do£u  m e n_t_T  y£e_N_ame : 

{ ISO  registration-authority  NBS  FTAM(  ) document(6)  Text(3)  parameter| 

Note:  "parameter"  is  a parameter  which  will  be  appended  to  the  registered 

identifier  in  an  OBJECT  IDENTIFIER. 

£o£ument_D£S c_Mp to_r  V_aJ_ue_:  Sequential  Text  File 

Document  Semantics: 


The  document  consists  of  an  unbounded  series  of  data  units.  Each  data 
unit  contains  one  data  element  which  is  a character  string.  Each  character 
is  taken  from  the  IA5  character  set. 

Scop£  an_d  F_i_el  d_  £f _A£p  J_ i£a£ i on j_ 

The  document  type  defines  the  contents  of  a file  for  storage  and  for 
transfer  using  FTAM. 

Note:  storage  refers  to  apparent  storage  within  the  virtual  filestore. 

Con_str_a  int_S£t_Name_: 

{iSO  standard  8571  constraint  set  name(5)  sequential  flat(2)( 

Additional  Constraints: 


FADU  Identity  will  be  limited  to  begin,  end,  first  and  next. 
Ab_st£a£t_Syntax_: 

The  abstract  syntax  of  each  data  element  is  an  instance  of  the  data  type 
IA5String. 

The  abstract  syntax  of  each  data  unit  is  specified  by  the  parameter. 
JAbs_t_ra£t_Sy_n£ax_  Name : 

{ISO  reg  istrat  ion-authority  NBS  FTAM(  ) abstract  syntax(2)  NBS-ASl(O)  [ 
£r£n£f£r_Syn£ax_: 

An  implementation  supporting  this  abstract  syntax  shall  support  a transfer 
syntax  for  each  data  element  obtained  by  applying  the  ASN.l  Basic  Encoding 
Rules  (ISO  8825)  to  the  data  elements  and  concatenating  the  resulting 
octets. 

Note:  This  transfer  syntax  is  not  self-delimiting. 

Implementations  may  optionally  support  other  named  transfer  syntaxes  for 
this  abstract  syntax. 

T_r£n£f£r_Syn£a_x  Name£ 

{ISO  reg  istrat  ion-authority  NBS  FTAM(  ) transfer  syntax(3)  NBS-TS 1 ( 0 ) f 
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Con_cat£n£tjon_ : 

Concatenation  of  a document  of  this  type  with  another  document  of  this 
type  is  possible  and  produces  a document  of  the  same  type  consisting  of  a 
series  of  IA5Strings  which  is  the  result  of  placing  the  series  of  IA5Strings 
from  one  file  of  this  type  after  the  last  IA5String  in  the  original  file. 

Note:  The  boundary  of  the  original  sequence  is  no  longer  visible. 

i m p]_  if  ic^at_ionj_ 

A document  of  type  NBS-4  can  be  accessed  as  a document  of  type  NBS-1  by 
specifying  a document  type  of  NBS-1  in  the  Contents  Type  parameter  on  the 
F-OPENrequest , and  limiting  access  context  to  UA  on  F-READ. 
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Entry  Number:  NBS-5 

Do£ument_Typ£  N_amej_ 

JlSO  registrat ion-authority  NBS  FTAM(  ) document(6)  8859Text(4)  parameter} 

Note:  "parameter"  is  a parameter  which  will  be  appended  to  the  registered 

identifier  in  an  Object  Identifier. 

£o£ume£t_D£S£rjiptor  £aj_u£:  Sequential  Text  File 

£o£ume£t_S£mant_i£S£ 

The  document  consists  of  an  unbounded  series  of  data  units.  Each  data 
unit  contains  one  data  element  which  is  a character  string.  Each  character 
is  taken  from  the  ISO  8859/1  character  set. 

_Sc£p£  an£  F_i£l  d_  £f _A£p]_ i£a£ i£n£ 

The  document  type  defines  the  contents  of  a file  for  storage  and 
transfer  using  FTAM. 

Note:  Storage  refers  to  apparent  storage  within  the  virtual  filestore. 

Constraint  Se£  N_ame£ 

{ISO  standard  8571  constraint  set  name(5)  sequential  flat(2)} 

Add  i£  i_on  a_l  _C£n£t£ajn  tS£ 

FADU  Identity  will  be  limited  to  begin,  end,  first  and  next. 

£bst£a£t_S£n£ax_: 

The  abstract  syntax  of  each  data  element  is  an  instance  of  the  data  type 
8859String. 

The  abstract  syntax  of  each  data  unit  is  specified  by  the  parameter. 

Ab£t£act_  Sy£t£x_N£me: 

jlSO  registration-authority  NBS  FTAM(  ) abstract  syntax(2)  NBS-ASl(O)} 
£r£n£f£r_S^n£ax_: 

An  implementation  supporting  this  abstract  syntax  shall  support  a transfer 
syntax  for  each  data  element  obtained  by  applying  the  ASN.l  Basic  Encoding 
Rules  (ISO  8825)  to  the  data  elements  and  concatenating  the  resulting 
octets. 

Note:  This  transfer  syntax  is  not  self-delimiting. 

Implementations  may  optionally  support  other  named  transfer  syntaxes  for  this 
abstract  syntax. 
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lr£n sf^r_S^n t_ax  Namej_ 

{iSO  registration-authority  NBS  FTAM(  ) transfer  syntax(3)  NBS-TSl(O)} 


Concatenat ion : 


Concatenation  of  a document  of  this  type  with  another  document  of  this 
type  is  possible  and  produces  a document  of  the  same  type  consisting  of  a 
series  of  8859Strings  which  is  the  result  of  placing  the  series  of 
8859Strings  from  one  file  immediately  following  the  last  8859String  in 
the  original  file. 

Note:  The  boundary  of  the  original  series  is  no  longer  visible. 

_S  imp]_  if  ic_at_  i on  j_ 

A document  of  type  NBS-5  can  be  accessed  as  a document  of  type  NBS-1  by 
specifying  a document  type  of  NBS-1  in  the  Contents  Type  parameter  on  the 
F-OPENrequest , and  limiting  access  context  to  UA  on  F-READ. 
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Entry  Number:  NBS-6 

£o£ume£t_Typ£  Name£ 

jlSO  registration-authority  NBS  FTAM(  ) document(6)  SEQUENTI AL( 5)  parameter} 

Note  - "parameter"  is  a parameter  which  will  be  appended  to  the  registered 
identifier  in  an  Object  Identifier. 

Do£ume£t_D£S£rjp£o£  V_aJ_ue_:  Sequential  File 


£o£ument_S  ema  nt_  i£S£ 

The  document  consists  of  an  unbounded  series  of  data  units.  Each  data 
unit  contains  an  unbounded  series  of  data  elements.  Each  data  element  is 
a data  type  from  the  set  of  primitive  data  types  defined  in  the  main 
body  of  this  document.  Each  data  unit  contains  the  same  data  element 
types  in  the  same  order  as  all  other  data  units. 

S_cop£  £nd_  F_i£l d_  of  Appl  ication: 

The  document  type  defines  the  contents  of  a file  for  storage  and 
transfer  using  FTAM. 

Note:  Storage  refers  to  apparent  storage  within  the  virtual  filestore. 

Constraint  Set  Name: 


{ISO  standard  8571  constraint  set  name(5)  sequential  flat (2)} 
Additional  Constraints: 


FADU  Identity  will  be  limited  to  begin,  end,  first,  and  next. 
Ab£t£a£t_Syn£ax_: 

The  abstract  syntax  of  each  data  element  is  an  instance  of  one  of  the 
primitive  data  types  defined  in  the  main  body  of  this  document. 

The  Abstract  syntax  of  each  data  unit  is  specified  by  the  parameter. 

£b£t£a£t_Syn£a_x  N_ame£ 

{ISO  registration-authority  NBS  FTAM(  ) abstract  syntax(2)  NBS-ASl(O)} 
optionally,  { I SO  reg  istrat ion-authority  NBS  FTAM(  ) abstract  syntax(2) 
NBS-AS2 ( 1 ) } 

Tr£n£f£r_S£n£a_x : 

An  implementation  supporting  this  abstract  syntax  shall  support  a transfer 
syntax  for  each  data  element  obtained  by  applying  the  ASN.l  Basic  Encoding 
Rules  (ISO  8825)  to  the  data  elements  and  concatenating  the  resulting 
octets. 

Note:  This  transfer  syntax  is  not  self-delimiting. 
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Implementations  may  optionally  support  other  named  transfer  syntaxes  for 
this  abstract  syntax. 

T_rans_f£r_Synt_ax_  Name : 

jlSO  reg istrat ion-author ity  NBS  FTAM(  ) transfer  syntax(3)  NBS-TSl(O)} 
Concat^nat^onj 

Concatenation  of  a document  of  this  type  with  another  document  of  this 
type  is  possible  and  produces  a document  of  the  same  type  consisting  of  a 
series  of  data  units  which  is  the  result  of  placing  the  series  of  data 
units  from  one  file  immediately  following  the  last  data  unit  of  the 
original  file. 

Note:  The  boundary  of  the  original  file  is  no  longer  visible. 

S_  i m p J_  if  i£at_  i on 

A document  of  type  NBS-6  can  be  accessed  as  a document  of  type  NBS-1  by 
specifying  a document  type  of  NBS-1  in  the  Contents  Type  parameter  in  the 
F-OPENrequest , and  limiting  access  context  to  UA  on  F-READ. 
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Entry  Number:  NBS-7 

Do£ument_Typ£  _Name_^ 

jlSO  reg istrat ion-authority  NBS  FTAM  ( ) document(6)  RAND0M(6)  parameter} 

Note:  "parameter"  is  a parameter  which  will  be  appended  to  the  registered 

identifier  in  an  Object  Identifier. 

Do£ume£t_D£S£Mp£o£  _Va]_u_e : Random  Access  File 

Document  Semantics: 


The  document  consists  of  an  unbounded  series  of  data  units.  Each  data 
unit  contains  an  unbounded  series  of  data  elements.  Each  data  element  is 
a data  type  from  the  set  of  primitive  data  types  defined  in  the  main  body 
of  this  document.  Each  data  unit  contains  the  same  data  types  in  the 
same  order  as  all  other  data  units  in  the  file. 

Sco_pe_  £nd^  F_iej£  £f _A£p]_ i£a£ i on j_ 

The  document  type  defines  the  contents  of  a file  for  storage  and  transfer 
using  FTAM. 

Note:  storage  refers  to  apparent  storage  within  the  virtual  filestore. 

Co£Str_a  i£t_Se  t_n  ame_: 

{ISO  registration-authority  NBS  FTAM(  ) constraint  set  name(5) 

NBS  Ordered  FI  at (2) } 


Ab£tract_S£nt£x: 

The  abstract  syntax  of  each  data  element  is  an  instance  of  one  of  the 
primitive  data  types  defined  in  the  main  body  of  this  document. 

The  Abstract  syntax  of  each  data  unit  is  specified  by  the  parameter. 

£bs_t_ra£t_Sy_n£a_x  £ame£ 

jlSO  registration-authority  NBS  FTAM(  ) abstract  syntax(2)  NBS-AS1 (0 ) } 
optionally,  {ISO  reg istrat ion-authority  NBS  FTAM(  ) abstract  syntax(2) 

NBS-AS2( 1 ) } 


Tr£n£f£r_Syn£ax_: 

An  implementation  supporting  this  abstract  syntax  shall  support  a transfer 
syntax  for  each  data  element  obtained  by  applying  the  ASN.l  Basic  Encoding 
Rules  (ISO  8825)  to  the  data  element  and  concatenating  the  resulting 
octets. 

Note:  This  transfer  syntax  is  not  self  delimiting. 

Implementations  may  optionally  support  other  named  transfer  syntaxes  for 
this  abstract  syntax. 
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T ransfer  Synta_x_Name_: 

jlSO  registration-authority  NBS  FTAM(  ) transfer  syntax(3)  NBS-TSl(O)  } 
Concaten  at^onj 

Concatenation  of  a document  of  this  type  with  another  document  of  this 
type  is  possible  and  produces  a document  of  the  same  type  consisting  of  a 
series  of  data  units  which  is  the  result  of  placing  the  series  of  data 
units  from  one  file  immediately  following  the  last  data  unit  of  the 
original  file. 

Note:  the  boundary  of  the  original  file  is  no  longer  visible. 

S_  i m p ]_  if  i c_a  t_  i£n_^ 

A document  of  type  NBS-7  can  be  accessed  as  a document  of  type  NBS-1  by 
specifying  a document  type  of  NBS-1  in  the  Contents  Type  parameter  of  the 
F-OPENrequest , and  limiting  access  context  to  UA  on  F-READ. 

A document  of  type  NBS-7  can  be  accessed  as  a document  of  type  NBS-6  by 
specifying  a document  type  of  NBS-6  in  the  Contents  Type  parameter  of  the 
F-OPENrequest. 


130 


Entry  Number:  NBS-8 


D_oc_umen_t_Ty_p_e  _Namej_ 

{ISO  reg istrat ion-author ity  NBS  FTAM(  ) document(6)  I NDEXED ( 7 ) pi  p2  } 

Note:  "pi"  and  "p2"  are  parameters  which  will  be  appended  to  the  registered 

identifier  in  an  Object  Identifier. 

D_o_cumen_t_De_S£rJ_pt_0£  V_aluiL:  Indexed  Sequential  File 

Document  Semantics: 


The  document  consists  of  an  unbounded  series  of  data  units.  Each  data 
unit  is  an  unbounded  series  of  data  elements.  Each  data  element  is  a 
data  type  from  the  set  of  primitive  data  types  defined  in  the  main  body 
of  this  document.  Each  data  unit  contains  the  same  data  types  in  the 
same  order  as  all  other  data  units  in  the  file. 

Each  data  unit  in  the  file  has  a key  associated  with  it.  The  key  of  each 
data  unit  is  of  the  same  data  type  as  the  key  of  all  other  data  units  in 
the  file  and  is  a single  data  element  from  the  set  of  primitive  data 
types  defined  in  the  main  body  of  this  document. 

Scope_  _an£  F_iej£  of _AjD_p J_ ic_ a£ i on£ 

The  document  type  defines  the  contents  of  a file  for  storage  and  for 
transfer  using  FTAM. 

Con_s£ra_  i£t_Set_Name_: 

{ISO  registration-authority  NBS  FTAM(  ) constraint  set  name(2) 

Indexed  Flat(l)} 

Ab£t_ra£t_S^n£ax_: 

The  abstract  syntax  of  each  data  element  is  an  instance  of  one  of  the 
primitive  data  types  defined  in  the  main  body  of  this  document. 

The  Abstract  syntax  of  each  data  unit  is  specified  by  the  parameter  pi. 

The  Abstract  syntax  of  the  data  unit  key  (FADU  Identifier)  is  specified 
by  the  parameter  p2. 

£b_st£a£t_Syn£ax_  _Name£ 

{ISO  registration-authority  NBS  FTAM(  ) abstract  syntax(2)  NBS-AS 1(0)} 
optionally,  { I SO  reg  istrat  ion-authority  NBS  FTAM(  ) abstract  syntax  (2) 
NBS-AS2( 1 ) } 
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T>ans_f£r_S^nt_ax_: 

An  implementation  supporting  this  abstract  syntax  shall  support  a transfer 
syntax  for  each  data  element  obtained  by  applying  the  ASN.l  Basic  Encoding 
Rules  (ISO  8825)  to  the  data  elements  and  concatenating  the  resulting 

octets. 

Note:  this  transfer  syntax  is  not  self-delimiting. 

Implementations  may  optionally  support  other  named  transfer  syntaxes  for 
this  abstract  syntax. 

Jra_ns_f_er_S^nt_ax_  Namej_ 

| ISO  reg istrat ion-authority  NBS  FTAM(  ) transfer  syntax(3)  NBS-TSl(O)  } 
Concatenat  i£nj_ 

A document  of  this  type  may  not  be  concatenated  with  a document  of  this 
type  or  any  other  type. 

S_  impj_  if  i£at_  ionj_ 

A document  of  type  NBS-8  can  be  accessed  as  a document  of  type  NBS-1  by 
specifying  document  type  NBS-1  in  the  Contents  Type  parameter  on  the 
F-OPENrequest , and  limiting  access  context  to  UA  on  F-READ. 

A document  of  type  NBS-8  can  be  accessed  as  a document  of  type  NBS-6  by 
specifying  document  type  NBS-6  in  the  Contents  Type  parameter  on  the 
F-OPENrequest. 

A document  of  type  NBS-8  can  be  accessed  as  a document  of  type  NBS-7  by 
specifying  document  type  NBS-7  in  the  Contents  Type  parameter  on  the 
F-OPENrequest . 
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Entry  Number:  NBS-9 

Do£umervt_Ty p£  Namej_ 

{ISO  reg istrat ion-authority  NBS  FTAM(  ) document(6)  FILE_DIRECT0RY(8) } 
Do£ume£t_D£S£rjjyt  0£  Vaj_ue:  F i 1 eD  i rect o ry  File 

D_0£U£en_t_S£m£n£  i£S£ 

The  document  consists  of  an  unbounded  sequence  of  data  units.  Each  data 
unit  consists  of  one  and  only  one  data  element  of  type  FileDirectoryEntry 
(a  complex  data  type  defined  in  the  main  body  of  this  document). 

Scope_  and_  _Fi£l  d_  £f _Ajd p_l_ i£a£ i£n j_ 

This  document  defines  the  contents  of  a file  for  transfer  (not  for  storage) 
using  FTAM. 

Con_s;tra_  i£t_S£t_Name.: 

{ISO  registrat ion-authority  NBS  FTAM(  ) constraint  set  name(5)  Sequential 
FI  at ( 1)  | 

Additional  Constraints: 


F ileDirectory  Files  may  be  Selected,  Opened,  Read,  Closed,  Created,  and 
Deleted.  They  may  not  be  Written  or  Modified  (except  as  a side-effect  of 
actions  performed  on  individual  files  contained  within  a F ileDirectory) . 
DataUnits  within  a FileDirectory  may  only  be  accessed  sequentially. 

_Ab£t£a£t_S^nt£x: 

An  indefinite  series  of  data  units.  Each  data  unit  contains  one  data 
element  of  type  F ileDirectoryEnt ry.  Each  data  element  consists  of  a 
required  FileName  and  a number  of  optional  Attributes. 

Ab£t£a£t_S£n£ax_  _Name£ 

{ISO  registration-authority  NBS  FTAM(  ) abstract  syntax(3)  filed irectory 

entry(O) } 


Tr£n£f£r_Sj)m£ax_: 

An  implementation  supporting  this  data  type  shall  support  a transfer 
syntax  for  each  data  value  obtained  by  applying  ASN.l  Basic  Encoding 
Rules  to  the  data  type  FileDirectoryEntry  in  the  data  value  and  concatenating 
the  resulting  octets. 

Note:  this  transfer  syntax  is  not  self-delimiting. 

Implementations  may  also  support  other  named  transfer  syntaxes  for  this 
abstract  syntax. 
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T>ans_f£r_S^nt_ax_  Namej_ 

|lSO  registration-authority  NBS  FTAM(  ) transfer  syntax(3)  NBS-TSl(O)} 
£oncatenatjon_:_ 

A document  of  this  type  cannot  be  concatenated  with  a document  of  this 
type  or  any  other  type. 

S_  imp]_  i_f  i£a  t_  ionj_ 

A document  of  this  type  cannot  be  simplified. 


134 


Part  2:  Constraint  Sets 


Constaint  Set  T it 1 e : NBS-Ordered  Flat 

Constraint  Set  Name: 

jlSO  registration-authority  NBS  FTAM(  ) constraint  set  name(5) 

NBS  Ordered  FI  at (2)  } 


F ield  of  Appl icat ion: 

Files  which  are  structured  into  a sequence  of  individual 
FADUs  and  to  which  access  may  be  made  on  a FADU  basis  by 
position  in  the  sequence. 

Node  Names: 

none 

Act  ions: 

Locate,  Read,  Replace,  Insert,  Erase 

Special  Action  Parameters: 

none 

Special  Action  Semantics: 

Erase:  Used  on  the  root  node  to  empty  the  file. 

When  used  on  a leaf  node,  it  leaves  a 
FADU  with  no  associated  data  unit. 

Insert:  Allowed  only  at  end  of  file.  The  new 

node  is  inserted  following  all  existing 
nodes  in  the  file  or  on  a leaf  node 
with  no  existing  data  unit.  The 
inserted  data  unit  is  associated  with  the 
currently  existing  leaf  node. 

Available  Access  Contexts: 

HA,  FA,  UA,  US 

Erase  and  Locate  Context: 

HA 

Constraints  on  Structure: 

The  root  node  shall  not  have  an  associated  data  unit. 
All  children  of  the  root  node  shall  be  leaf  nodes 
and  may  have  an  associated  data  unit.  All  arcs  from 
the  root  node  shall  be  of  length  one. 

Creation  State: 

Root  node  without  an  associated  data  unit. 

FADU  Identity: 

begin,  end,  first,  last, 
current,  next,  previous, 

traversal  number  (greater  than  or  equal  to  one) 

Location  After  Open: 

root  node 

Beg  inn  in  g of  File: 

root  node 

End  of  F ile: 

No  node  is  selected.  Previous  gives  the  last  node  in 
the  traversal  sequence,  current  and  next  result  in  an 
error. 
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Constraint  Set  Title:  Indexed  Flat 


Constraint  Set  Name: 

{ISO  registration-authority  NBS  FTAM(  ) constraint  set  name(5) 

NBS  Indexed  FI  at ( 1) } 


F ield  of  Appl icat ion: 

This  constraint  set  is  for  representing  single  key 
ISAM  files  where  the  keys  are  the  FADU  identifiers 
for  the  leaf  nodes.  The  keys  are  restricted  to  being 
single  primitive  data  types,  and  restricted  to 
all  keys  being  of  the  same  primitive  data  type. 

Node  Names: 

Any  single  primitive  data  type. 

Act  ions: 

Locate,  Read,  Replace,  Insert,  Erase 

Special  Action  Parameters: 

none 

Special  Action  Semantics: 

Locate:  The  specified  FADU  is  made  the  current 
FADU.  If  the  FADU  Id  form  is  used,  the 
least  recently  inserted  FADU  with  the 
specified  FADU  at  level  1 is  located. 

Read:  Allowed  at  root  and  leaves.  If  there  is 

another  FADU  after  (in  pre-order  traversal 
order)  the  one  read  with  the  same  FADU  Id, 
a diagnostic  on  TRANSFER_END  will  indicate 
this  fact. 

Insert:  Insert  the  specified  FADU  (level  1 only)  in 
the  lexical  order  of  the  key  primitive  data 
type.  If  there  is  already  another  FADU  with 
the  specified  FADU  Id,  insert  the  new  one 
after  (in  pre-order  traversal)  the  existing 
FADUs  and  indicate  that  this  was  done  via  a 
diagnostic  on  TRANSFER_END. 

Replace:  Allowed  only  at  leaves  and  only  in  access 
context  US  (DU  only  w/o  delimiters).  Only 
allowed  with  write  operation  of  "current" 
(i.e.,  preceded  by  locate)  or  "Previous" 
(i.e.,  preceded  by  read). 

Erase:  If  the  addressed  FADU  is  the  root,  the  file 

is  reduced  to  the  initial  state. 

Available  Access  Contexts: 

HA,  FA,  UA,  US 

Erase  and  Locate  Context: 

HA 
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Constraints  on  Structure: 

The  root  node  shall  not  have  an  associated  data  unit 
or/and  FADU  Id.  All  children  of  the  root  node  shall 
be  leaf  nodes  and  shall  have  an  associated  data  unit 
and  FADU  Id.  All  arcs  from  the  root  node  shall  be  of 
length  one.  Some  primitive  types  may  not  be  supported 
as  keys. 

Creation  State: 

Root  node  without  an  associated  data  unit  or  FADU  Id. 

FADU  Identity: 

begin,  end, 

current,  next,  previous, 
FADU  Id 

Location  After  Open: 

root  node 

Beginning  of  File: 

root  node 

End  of  File: 

No  node  is  selected.  Previous  gives  the  last  node 
in  the  traversal  sequence,  current  and  next  result 
in  an  error. 
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Part  3:  Abstract  Syntaxes 

Abstract  Syntax:  NBS-AS1 


Abstract  Syntax  Name: 

{ISO  registration-authority  NBS  FTAM(  ) Abstract  Syntax(2)  Basic(O)} 

Abstract  Syntax  Definition: 

DE  : :=Choice IlNTEGER, 

BOOLEAN, 

IA5String, 

8859String, 

OCTETSTRING, 

Un  iversalTime, 

General izedT ime. 

Null} 

8859String  ::=  [PRIVATE  1]  Implicit  8859CharacterString 

Transfer  syntax  name:  — 8859CharacterString  is  a string  of  characters  from 

— the  ISO  8859  character  set 

{ISO  registrat ion-authority  NBS  FTAM(  ) Transfer  Syntax(4)  NBS-TS1  (0)} 


Abstract  Syntax:  NBS-AS2 

Abstract  Syntax  Name: 

{ISO  registrat ion-authority  NBS  FTAM(  ) abstract  syntax(2)  Float ingPoint(l) } 
Abstract  Syntax  Definition: 

Float ingPointNumber  ::=  [PRIVATE  0]  CHOICE 
' finite  [0]  IMPLICIT  SEQUENCE 


Sign 


I 


I 


( 


Sign , 

mantissa  BITSTRING, 
exponent  INTEGER 


infinity  [1]  IMPLICIT  Sign, 
signalling  NaN  [2]  Implicit  NaN, 
quietNaN  [3]  IMPLICIT  NaN, 
zero  [4]  IMPLICIT  NULL 


INTEGER  ({positive(O) , negative(l) 


t 


NaN  INTEGER 


Transfer  Syntax  Name: 

{ISO  reg istrat ion-authority  NBS  FTAM(  ) transfer  syntax(3)  NBS-TSl(O)  } 
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Abstract  Syntax:  NBS-AS3 


Abst£3£t_S^nt_a_x  _Namej_ 

) ISO  registration-authority  NBS  FTAM(  ) abstract  syntax(2)  FileDirectoryElement(2) } 

A_bs_t_ra£t_Sy_nt_ax_  D_e^in_it_i_onj_ 

FileDirectoryEntry  ::=  [PRIVATE  2]  IMPLICIT  SEQUENCE) 

fileName  Graphicstring, 

ContentsTypef 

ContentsType  ::=  CHOICE 

document-type-Name[0]  IMPLICIT  OBJECT  IDENTIFIER, 
constraint-set-and-abstract-syntax  [1]  IMPLICIT  SEQUENCE) 

constra int-set-Name[0]  IMPLICIT  OBJECT  IDENTIFIER, 
abstract-syntax-Name[l]  IMPLICIT  OBJECT  IDENTIFIER f . 

ZriP sf£r_S^n tax_  N_amej_ 

)lS0  reg istrat ion-authority  NBS  FTAM(  ) transfer  syntax(3)  NBS-TS1 (0) f 


139 


Part  4:  Transfer  Syntaxes 

Transfer  Syntax:  NBS-TS1 

Transfer  Syntax  Name: 

{ISO  registration-authority  NBS  FTAM(  ) transfer  syntax(3)  NBS-TSl(O)} 
Encoding  Rules: 

ASN.l  Basic  Encoding  Rules  shall  apply 
The  first  bit  of  a "fraction"  must  be  "1" 

Transfer  Syntax  Definition: 

The  transfer  syntax  shall  be  that  which  results  from  applying  the  encoding 
rules  described  above  to  the  individual  data  elements. 


ADDENDUM  1 


Note  on  FTAM  and  X.400  Character  Sets 


On  July  21,  1986  a group  of  twelve  individuals  from  the  FTAM  and  X.400 
SIGs  met  to  resolve  differences  in  recommended  use  of  character  sets. 

The  following  was  agreed  (in  favor,  9;  opposed,  2;  abstaining,  1)  by 
these  individuals: 

"Both  SIGs  should  implement  IA5  for  the  current  phase  of  development,  and 
independently  support  expanded  character  sets.  It  is  recommended  that 
the  FTAM  and  X.400  SIGs  support  both  8859/1  and  6937/2  in  the  next  phase 
of  their  agreements." 

Neither  SIG  brought  forward  to  the  plenary  on  Thursday  July  24,  1986  a 
recommendation  on  this  issue.  However,  it  was  raised  for  plenary  discussion. 
The  plenary  felt  (in  favor,  22;  opposed,  3;  abstaining,  1)  that  this 
information  should  be  carried  in  some  form  in  this  document  in  addition 
to  inclusion  in  the  minutes.  Hence,  it  is  included  as  an  addendum  so  as 
to  keep  the  information  associated  with  this  document  while  showing  that 
it  has  not  been  accepted  for  inclusion  in  the  main  body  of  this  document. 
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You  will  receive  the  documents  from  the  next  workshop  by  either  attending 
the  workshop  or  completing  and  returning  the  form  below. 

READER  RESPONSE  FORM 


Please  retain  my  name  for  the  next  mailing  of  the  NBS/OSI  Implementors 
Workshop 

NAME  

ADDRESS 


PHONE  NO. 


Mail  this  page  to:  Kim  Brink 

National  Bureau  of  Standards 
Bldg.  225/B217 
Gaithersburg,  MD  20899 
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